Mac-Source 1994 July/Mac-Source_July_1994.iso/Other Langs/python/mail1992

Text File | 1994-04-01 | 967.9 KB | 25,582 lines | [TEXT/R*ch]

Received: by charon.cwi.nl with SMTP; Fri, 22 Nov 1991 11:47:14 +0100
Received: by voorn.cwi.nl with SMTP; Fri, 22 Nov 1991 10:47:13 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Welcome to the Python list!
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 22 Nov 91 11:47:11 +0100
Sender: [e-mail]

Welcome to the Python mailing list!  This message acknowledges that
you are now on the list.

The list is intended for discussion of and questions about all aspects
of design and use of the Python programming language.  The list is not
moderated, i.e., everything you send to it is immediately forwarded to
anybody else on the list -- so be a little careful in what you write.

Send messages for the entire list to [e-mail].  Send
(un)subscription request and other messages for the list administrator
(that's me) to [e-mail] (that's python-list-request,
not python-request!).

A high-level description of Python can be found in section two of the
following paper:

    Guido van Rossum, Jelke de Boer: Linking a Stub Generator
    (AIL) to a Prototyping Language (Python); in: Spring 1991
    EurOpen Conference Proceedings, May 20-24, 1991, Troms/o,
    Norway.

The latest Python release is always available by anonymous ftp from
ftp.cwi.nl, in directory pub.  Chances are that it is also available
from wuarchive.wustl.edu, which may be faster for U.S. based users.
The release contains full source and documentation, and runs on most
UNIX workstations and on Macintosh computers (who'll do an MS-DOS
port?)

--Guido van Rossum, CWI, Amsterdam
"Is it a bird? No! Is it a plane? No! It's bicycle repair man!"










Received: by charon.cwi.nl with SMTP; Sat, 23 Nov 1991 16:35:14 +0100
Received: by voorn.cwi.nl with SMTP; Sat, 23 Nov 1991 15:35:13 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: comments on Python
Date: Sat, 23 Nov 91 16:35:12 +0100
From: [e-mail]

[To get some discussion going on the list, I post (with permission) a
reply I sent to a message from one of my beta testers, which discusses
various aspects of Python.  Almost the entire original message is quoted
using ">" in the left margin.]

>From: amdcad!bitblks![e-mail]
>
>The package:
>    mode_t is not defined for sunos-3
>    waitpid is not defined for sunos-3
>
>    That is, these two do not exist for sunos-3 so fake defns
>    should be provided.

I'll try.  Is there some predefined symbol by which I can recognize
sunos-3 from SunOS 4?

>    The error message when you forget to indent (as in the
>    example below) is very cryptic.
>        while b<10:
>        print b,
>    Not sure what you can do though.

True, all too true.  In fact there is only a single error message for
syntax errors.  Some day I'll put in a decent parser.

>    You really should number pages in tut.tex.  A pain to keep
>    them sorted.

When I print it the pages are numbered.  Maybe you should shorten the
page height in "myformat.sty" -- I set it for European paper size,
which is about 12 inches high, while yours is likely to be 11 inches.

>I like python on the whole and don't like perl.  Perl lacks in
>data structures (one can't have an array of an array or an array
>of dictionaries) and has a very irregular syntax.  Lack of
>explicit declarations means you can misspell a word and not know
>it until the program mis-behaves.  It has dynamic scoping and uses
>lexical hooks like & @ $ etc. to mean different things.

Actually, Python lacks explicit declarations as well -- and indeed it
is one of its weaknesses that a misspelled variable is only detected
when the actual line of code is executed (or never, if an *assignment*
is misspelled and there was a previous assignment to the same name).
Clever compile-time checking can relieve this in part, although for
instance variables (assignable attributes in Python's parlance) it
gets tough.

>BUT.... the fact remains that perl is still a lot easier to hack
>something in, due to the conciseness of its notation, some very
>powerful operators, multiple features for doing the same thing,
>pattern matching operators, and lots of examples.  If you try to
>translate some existing perl scripts to python, you can see for
>yourself what I am saying.  Or may be, what is needed is lots of
>useful text munging examples.

Python on purpose gives you one way to do most things (one way for
each things, not one way for all things together!), on the account
that it makes the choice easier, and makes programs more readable --
you are less likely to encounter unobvious code for obvious actions.
There is a demo directory in the distribution which tries to give the
examples, and part of the library is also intended as such -- but more
examples always help.  Text munging wasn't the first purpose of the
language, although it is an important tool for many applications, just
like arithmetic.

>Anyway, here are some suggestions.  I believe python can be made
>significantly friendlier by adding a few choice features but
>without sacrificing its clean and sound design.  May be a lot of
>the things user might want can be added to the library.

I will resist creeping featurism wherever I can, but I have indeed
been adding features lately (e.g., shift/mask operators).

>How about providing assignment operators?  Some time one has to
>build a thing piece-meal and this sort of operators are very
>handy.  The semantics are clear:
>
>    <var> <op>= <expr>  === <var> = <var> <op> <expr>
>
>Example:
>    a = 'ba '
>    a *= 2                  # a = 'ba ba'
>    a += 'black sheep'      # a = 'ba ba black sheep'

Agreed.  Now that the parser can actually recognize two-character
operators, adding these wouldn't be so hard (except that the grammar
tables will grow again :-( ).

>I would also like the capability of overloading standard operators
>for predefined and user defined classes.  Thus instead of
>       result.append(b)
>I should be able to say
>    result += b
>or better still,
>    result += [a,b,c]

The latter should automatically work if we let x += y be syntactic
sugar for x = x+y.  Note that result = result + [x] has a different
meaning than result.append(x), although in many cases it doesn't
matter: result.append(x) modifies the existing object that result is
bound to, while result = result+[x] creates a new list (the
concatenation of result and [x]) and binds result to it, forgetting
the object to which result was bound previously.  If there was another
reference to that object, e.g., through an assignment "z = result"
earlier on, the value of z is unchanged by the second form, but
modified by the first form.  Confusing?  Yes, but this is a lot better
than allowing arbitrary pointers!

>How come python doesn't have structures?  Do I have to use classes
>for this ala C++?  Ugh!

For simple cases you can use tuples -- this keeps values together but
you reference them by position.  For larger cases you indeed have to
use classes -- but what's ugly about that?

>As in perl I would like to be able to assign elements of an array
>to individual variables or vice-versa.  This is very handy.  For
>example, the following code picks out size and name of all the
>files in the current directory.
>
>    open(LS, "ls -l|") || die "ls failed";
>    for (<LS>) {
>        ($perm,$links,$user,$size,$Mon,$day,$YorT,$name) = split;
>        print "$size\t$name\n";
>    }
>
>Granted that a list is not the same as a tuple so perhaps we
>need a special `coercion' operator or assignment. I am hoping
>for something like
>
>    ls = open('ls -l', '<')
>    if not ls: die('ls failed')
>    while line = ls.readline():
>        perm,links,size,mon,day,YorT,name =~ tuple split(line)
>        print size, '\t', name, '\n'
>
>    Notes:
>    '<' in open implies pipe-from
>    '>' in open should imply pipe-to
>    operator tuple coerces a list to a tuple.
>    operator =~ allows mismatched tuples on the LHS and RHS.

You can do this!  If a is a list of three elements, just write
    [x, y, z] = a
A working version of this program is:

import posix, string
pipe = posix.popen('ls -l', 'r')
for line in pipe.readlines():
    if line[:5] = 'total': continue
    [perm,links,user,group,size,mon,day,YoT,name] = string.split(line)[:9]
    print size, '\t' + name

The [:9] tacked to the end of the assignment does more or less what your
proposed =~ does.  Note that "ls -l" on my system outputs both the
username and the group name, and outputs a first line starting with
'total', which makes this kind of scripts so dangerously non-portable.
Another way (oh no!) to do this in Python was to use posix.opendir()
and posix.stat(); I'll let that be an exercise for the reader (actually
there are examples of this in the demo subtree).

>The support for regular expressions is built in perl.  This is
>very handy.  Perhaps an equivalent capability can be added via a
>library module?  Though that is likely to be very slow (just like
>the operations in string.py).

There's already a built-in module 'regexp', which does what you want.
Access is slightly clumsier than Perl (there's no special syntax to
handle regular expressions) and the expressions are simpler (just
Henry Spencer's regexp package), but what you want is there...

>Got to go.

Me too.

>-- Bakul

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"All right, it's a fair cop, but society is to blame."










Received: by charon.cwi.nl with SMTP; Sat, 23 Nov 1991 16:38:40 +0100
Received: by voorn.cwi.nl with SMTP; Sat, 23 Nov 1991 15:38:39 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: comments on Python
From: amdcad!bitblks![e-mail]
Date: Sat, 23 Nov 91 16:38:38 +0100
Sender: [e-mail]

[Another repost; ">" is me, plain is Bakul.  --Guido]

> I'll try.  Is there some predefined symbol by which I can recognize
> sunos-3 from SunOS 4?

I just added #ifdef sun, which is defined.  I don't know if sunOS 4
adds another define to distinguish it from earlier versions.

> When I print it the pages are numbered.  Maybe you should shorten the
> page height in "myformat.sty" -- I set it for European paper size,
> which is about 12 inches high, while yours is likely to be 11 inches.

Ah, that explains it.  Would be nice if your style worked for
either size (may be we need a4.sty).

> Actually, Python lacks explicit declarations as well -- and indeed it

True.  I was just adding up perl's sins!  It seems funny that you
have to import definitions but not declare variable!  Even a `def
<var>' will help.  I would also like `def <var> <type>' or
something similar.

> Python on purpose gives you one way to do most things (one way for
> each things, not one way for all things together!), on the account
> that it makes the choice easier, and makes programs more readable --

Perl does go overboard in the number of choices it provides but
common idioms can become easier to read if they have a special
form.  Even though x[i*j] += y is equiv. to x[i*j] = x[i*j] + y, I
favor the first form.  And the same is true of other idioms.  So
`only one way' seems limiting.

> There is a demo directory in the distribution which tries to give the
> examples, and part of the library is also intended as such -- but more
> examples always help.

You may also want to post new useful scripts to lang.misc to
stimulate discussion (and may be flames.  But we can ignore those)
and to give people an opportunity to see python in action.
(Mailing lists tend to be overwhelming for beginners).

> >I should be able to say
> >       result += b
> >or better still,
> >       result += [a,b,c]
>
> The latter should automatically work if we let x += y be syntactic
> sugar for x = x+y.  Note that result = result + [x] has a different
> meaning than result.append(x)...

I understand the difference -- that is why I think overloading
operators is worth considering.  The '+' in result += b is a
different operator from 'result + [a,b,c]'.  As long as the type
signature is different, there should not be a problem in resolving
operators, right?

> For simple cases you can use tuples -- this keeps values together but
> you reference them by position.  For larger cases you indeed have to
> use classes -- but what's ugly about that?

Because all I want is to name tuple constituents.  A class is a
much heavier weight feature.  I think what is lacking is *syntax*
as in a referentially transparent language you can easily translate
tuple.field to tuple.position.  I suppose you do need declarations.

> You can do this!  If a is a list of three elements, just write
>        [x, y, z] = a

Good!  Guess I should reread the tutorial!

> import posix, string
> pipe = posix.popen('ls -l', 'r')
> for line in pipe.readlines():
>        if line[:5] = 'total': continue
>        [perm,links,user,group,size,mon,day,YoT,name] = string.split(line)[:9]
>        print size, '\t' + name

This is exactly the kind of thing that will let people compare
python with other languages.  Shouldn't that `string.split' be
`line.split'?  Why is '\t' + name preferable to '\t', name?

> 'total', which makes this kind of scripts so dangerously non-portable.

Though that does not depend on the scripting language.

> There's already a built-in module 'regexp', which does what you want.
> Access is slightly clumsier than Perl (there's no special syntax to
> handle regular expressions) and the expressions are simpler (just
> Henry Spencer's regexp package), but what you want is there...

I should really get reacquainted with python.  It has been while
and my short term memory is getting worse:-(

- -- bakul

PS: one more comment.  The fact that for built in things you can
use unqualfied procedures (operators?) such as `len(string)' but
for user defined class instances you have to do `foo.len()' seems
inconsistent -- I don't know what can be done though.

------- End of Forwarded Message











Received: by charon.cwi.nl with SMTP; Sat, 23 Nov 1991 17:29:59 +0100
Received: by voorn.cwi.nl with SMTP; Sat, 23 Nov 1991 16:29:58 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: comments on Python
In-Reply-To: Your message of "Sat, 23 Nov 91 16:38:38 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Sat, 23 Nov 91 17:29:57 +0100
Sender: [e-mail]

[Here's my reply to Bakul.  ">>" is me, ">" is Bakul, plain is me again.
We begin with some boring details... --Guido]

>> I'll try.  Is there some predefined symbol by which I can recognize
>> sunos-3 from SunOS 4?
>
>I just added #ifdef sun, which is defined.  I don't know if sunOS 4
>adds another define to distinguish it from earlier versions.

I don't know either.  Anybody else on the list know how ti distinguish
SunOS 4.x from 3.x?

>> When I print it the pages are numbered.  Maybe you should shorten the
>> page height in "myformat.sty" -- I set it for European paper size,
>> which is about 12 inches high, while yours is likely to be 11 inches.
>
>Ah, that explains it.  Would be nice if your style worked for
>either size (may be we need a4.sty).

There are some comments in the style file that explain how to patch it for
US size paper.  Maybe I should distribute it with US size paper turned on
by default.

>> Actually, Python lacks explicit declarations as well -- and indeed it
>
>True.  I was just adding up perl's sins!  It seems funny that you
>have to import definitions but not declare variable!  Even a `def
><var>' will help.  I would also like `def <var> <type>' or
>something similar.

I don't believe explicit declarations of local variables is a good idea
for a language intended for casual programming, like Python.  Instead, a
compile-time checker should be written that detects use of undefined
variables orq assignment to variables that are never used.  Remember, *use*
of an undefined variable is a run-time error in Python -- in a sense, the
assignment that gives the variable a value is its declaration.

Importing definitions (modules) is the equivalent of assigning a value to
a variable, not of declaring a variable.  Hence there is no inconsistency.

>> Python on purpose gives you one way to do most things (one way for
>> each things, not one way for all things together!), on the account
>> that it makes the choice easier, and makes programs more readable --
>
>Perl does go overboard in the number of choices it provides but
>common idioms can become easier to read if they have a special
>form.  Even though x[i*j] += y is equiv. to x[i*j] = x[i*j] + y, I
>favor the first form.  And the same is true of other idioms.  So
>`only one way' seems limiting.

Sure.  I'm not using this rule to make Python the absolutely smallest
language possible.  I just prefer to show people that there is already a
way to do what they want (if this is so) rather than adding yet another
feature.  There are actually pretty good reasons to include assignment
operators like "+=" and I'd like to add them.

>> There is a demo directory in the distribution which tries to give the
>> examples, and part of the library is also intended as such -- but more
>> examples always help.
>
>You may also want to post new useful scripts to lang.misc to
>stimulate discussion (and may be flames.  But we can ignore those)
>and to give people an opportunity to see python in action.
>(Mailing lists tend to be overwhelming for beginners).

I tried this long ago, but stopped because there seemed too little
interest.  Also, it is hard to write good examples that are also useful:
most code either is useful but not written in the absolutely cleanest way
possible, or it is really clean and easy to follow, but lacks useful
options.  Maybe someone could go through the demo directory, pick a few
examples that are clean enough to show to outsiders, and post them...

>> >I should be able to say
>> >       result += b
>> >or better still,
>> >       result += [a,b,c]
>>
>> The latter should automatically work if we let x += y be syntactic
>> sugar for x = x+y.  Note that result = result + [x] has a different
>> meaning than result.append(x)...
>
>I understand the difference -- that is why I think overloading
>operators is worth considering.  The '+' in result += b is a
>different operator from 'result + [a,b,c]'.  As long as the type
>signature is different, there should not be a problem in resolving
>operators, right?

Unfortunately, this would require deferral of operator resolution to
run-time, and could cause quite a few surprises.  Consider the following
example.  Let's say we have a function to add an element to a list if it
is not already in the list (this could be part of a package emulating set
semantics using lists):

    def add_elem(set, elem):
        if elem not in set:
            set += elem

Normally, the last line would be interpreted (using your operating
overloading) as set.append(elem).  However, if we had a set of lists, or a
set of sets (quite a common construct in mathematics; lists of lists are
also very useful in Python), it would be interpreted as "set = set +
elem"! In a language with static typing, this cannot occur, but Python has
very dynamic typing...  Changing that would make it an entirely different
language.

>> For simple cases you can use tuples -- this keeps values together but
>> you reference them by position.  For larger cases you indeed have to
>> use classes -- but what's ugly about that?
>
>Because all I want is to name tuple constituents.  A class is a
>much heavier weight feature.  I think what is lacking is *syntax*
>as in a referentially transparent language you can easily translate
>tuple.field to tuple.position.  I suppose you do need declarations.

I'm still not convinced that it is necessary to this to the language.
Because of the dynamic typing, the translation of tuple.field to
tuple[position] has to be done at run-time.  The implementation of class
instances already provides such a mapping (using a dictionary).  Why do
you think classes are heavy-weight?  All you need is to place

    class Struct(): pass

somewhere early in your module, and then you can create structures using

    x = struct()

and fill them with statements like

    x.width = 14
    x.height = 200


>> You can do this!  If a is a list of three elements, just write
>>        [x, y, z] = a
>
>Good!  Guess I should reread the tutorial!

I'm not absolutely sure it's in there (the tuturial is already
overloaded).  It will be in the reference manual I'm writing.

>> import posix, string
>> pipe = posix.popen('ls -l', 'r')
>> for line in pipe.readlines():
>>        if line[:5] = 'total': continue
>>        [perm,links,user,group,size,mon,day,YoT,name] = string.split(line)[:9]
>>        print size, '\t' + name
>
>This is exactly the kind of thing that will let people compare
>python with other languages.  Shouldn't that `string.split' be
>`line.split'?  Why is '\t' + name preferable to '\t', name?

No it's definitely "string.split(line)".  The point is, for better or for
worse, strings don't have attributes, so all string operations that aren't
built-in operations (like "+" for concatenation) have to be functions.
The module "string" is a collection of such functions.

I wrote '\t' + name because '\t', name inserts an extra space between the
tab and the name (print *always* inserts spaces between output items,
except if an item ends in '\n').

>> 'total', which makes this kind of scripts so dangerously non-portable.
>
>Though that does not depend on the scripting language.

It does, because sime scripting languages offer no alternative (e.g., in
"sh" scripts or awk, you just have to parse "ls" output for this case,
while Perl and Python also offer a direct interface to the stat() system
call.

>> There's already a built-in module 'regexp', which does what you want.
>> Access is slightly clumsier than Perl (there's no special syntax to
>> handle regular expressions) and the expressions are simpler (just
>> Henry Spencer's regexp package), but what you want is there...
>
>I should really get reacquainted with python.  It has been while
>and my short term memory is getting worse:-(

Go ahead -- the more you use it, the more you'll like it!

>- -- bakul
>
>PS: one more comment.  The fact that for built in things you can
>use unqualfied procedures (operators?) such as `len(string)' but
>for user defined class instances you have to do `foo.len()' seems
>inconsistent -- I don't know what can be done though.

len() is a border case: it applies to several different types (all
sequence and dictionary types), some of which currently have no methods
(strings and tuples).  I think len(str) is prettier than str.len(), but
this isn't a very important reason.  On the other hand, a limited number
of unqualified built-in functions is probably necessary -- would you
prefer to write (x + 1).abs() rather than abs(x + 1) ???

In any case, this is only done for the most important built-in things.
Other built-in functionality is accessed using imported (built-in)
modules, but some things just need to be available at all times.  The
alternative, which I consider to be worse, would be to turn them all into
keywords.  The "raise" statement is a border case: I played with the idea
of making it a built-in function.  However, making it a statement puts it
on the same level as "return", "break" and "continue", which also
unconditionally pass control to some outer level.  With "raise" being a
statement, it can profit when the syntax is tightened to disallow code
following such branching statements.  Emacs Python mode should
automatically dedent after one of these (it doesn't yet -- anyone care
enough to patch it?)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
Honary Member, Royal Society for Putting Things on Top of Other Things










Replied: Wed, 04 Dec 91 18:48:33 +0100
Replied: ""Steven D. Majewski" <[e-mail]> [e-mail]"
Received: by charon.cwi.nl with SMTP; Wed, 4 Dec 1991 17:44:59 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa08369;
          4 Dec 91 11:44 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA01673; Wed, 4 Dec 91 11:36:05 EST
Date: Wed, 4 Dec 91 11:36:05 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Why no index for tuples or strings ?


Most of the functions that operate on mutable sequences but NOT on
immutable ones are obviously there because they DO CHANGE the sequence.
BUT: why no  string.index() or tuple.index() ?

Is this just an oversight ?
If not, what is the reason?
( Just in case it was the documentation that was wrong, I tried this, and
 it does in fact fail. )

>>>from string import lowercase
>>>L = []
>>>T = ()
>>>for x in lowercase:
...  L.append( x )
...  T = T + ( x, )
...
>>>L.index('k')            # this works
10

>>>T.index('k')            # these two
>>>lowercase.index('k')        # fail


======== "If you have a hammer, find a nail" - George Bush,'91  =========
 Steven D. Majewski        University of Virginia Physiology Dept.
 [e-mail]        Box 449 Health Sciences Center
 Voice: (804)-982-0831        1600 Jefferson Park Avenue
 FAX:   [phone]        Charlottesville, VA 22908










Received: by charon.cwi.nl with SMTP; Wed, 4 Dec 1991 18:51:22 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa12252;
          4 Dec 91 12:50 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA01741; Wed, 4 Dec 91 12:42:08 EST
Date: Wed, 4 Dec 91 12:42:08 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: WHY PYTHON?


Why Python ?
I mean that question in 2 senses.

(1) Why the name "python" ?

(2) What role do you see python as fulfilling or in what direction do
you anticipate its evolution ?
( Perhaps it *can* be "all things to all people", but I wonder if there
aren't some potential conflicts ahead between python as:
   an interactive environment & command interpreter.
   a command scripting language
   a general purpose scheme-like symbol processing language
   a GENERAL purpose high level language for everything else
   an object oriented language
   whatever else...
I see python as potentially good in all these roles, but perhaps
the needs and priorities differ. An interactive language needs
conciseness, even if it creates syntactic irregularity. Regularizing
built-in data types with user-objects, which would seem to be one
desirable direction, might conflict with adding more built-in's
( like vectors, for example ) for effeciency. )

---
 One issue I will raise ( re: regularizing built-ins and objects ):
 I suggest that hooks to change the print representation of an object
 are desirable. Obviously, for user objects, one can write a '.print'
 method function for the object, and maintain the convention of
 consistently using that name ( or "._print" ). But it would be better
 if you could override "`" (backquote) for both user objects and
 built-in data types. COMMON-LISP has this capability: It comes in
 handy when you are dealing with large vectors/lists/tuples/etc. Instead
 of waiting for your terminal to print out a thousand number, you can
 change the print representation to be something like:
  "List of size=1024 : ( 0, 1, 2,  ... 1021, 1022, 1023 )"
 Minimally, you should be able to change the string backquote returns.
 Maximally, you should be able to change the action when evaluating a
 symbol, i.e. , currently typing a symbol causes the equivalent to
 'print `symbol` ' to occur. Instead of:
   >>> a = [ 1,2,3,4,5 ]
   >>> a
   [ 1, 2, 3, 4, 5 ]
 Typing 'a' could cause a plot of the values in a window.
 ( Probably this last is too much, and should be left to a user-level
   interpreted written on top of python. )

 In general, I think that regularization of built-in data types and
 user written objects is a good direction: allow operators like '+' to
 be defined for user-objects, and let built-ins be used as classes for
 inheritance. i.e. "class myList() = list: "

 - Steve


======== "If you have a hammer, find a nail" - George Bush,'91  =========
 Steven D. Majewski        University of Virginia Physiology Dept.
 [e-mail]        Box 449 Health Sciences Center
 Voice: (804)-982-0831        1600 Jefferson Park Avenue
 FAX:   [phone]        Charlottesville, VA 22908










Received: by charon.cwi.nl with SMTP; Wed, 4 Dec 1991 18:48:36 +0100
Received: by voorn.cwi.nl with SMTP; Wed, 4 Dec 1991 17:48:34 GMT
Message-Id: <[e-mail]>
To: "Steven D. Majewski" <[e-mail]>
Cc: [e-mail]
Subject: Re: Why no index for tuples or strings ?
In-Reply-To: Your message of "Wed, 04 Dec 91 11:36:05 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Wed, 04 Dec 91 18:48:34 +0100
Sender: [e-mail]

>Most of the functions that operate on mutable sequences but NOT on
>immutable ones are obviously there because they DO CHANGE the sequence.
>BUT: why no  string.index() or tuple.index() ?
>
>Is this just an oversight ?
>If not, what is the reason?

Umm, there isn't a real good reason.  One thing I can say in my
defense is that string and tuple objects have no methods at all, all
operations on these are done with built-in operations like "+" and
"[...]", so adding an "index" method would be a bit of a change in the
structure.

For tuples, I suspect such a function would rarely be used; I think
that is most cases where x.index() would be useful, x is generally a
list, whose contents varies in time, rather than a tuple (which cannot
change easily).

For strings, there is a built-in module "string" which exports a
function "index" which searches for substrings, so you can say

    string.index('one two three', 'two')

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Oh my god, he's fallen off the edge of the cartoon."










Received: by charon.cwi.nl with SMTP; Wed, 4 Dec 1991 20:02:44 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa16972;
          4 Dec 91 14:02 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA01825; Wed, 4 Dec 91 13:54:11 EST
Date: Wed, 4 Dec 91 13:54:11 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: A useful quickie function to read data.

I am already finding python quite useful.
I'll wait till I debug them before I post any full programs,
( I've got a 'du' in python that does't follow links or mount points
  and takes a max-depth and/or a prune-path argument to limit
  how detailed a listing it generates. There is some bug with
  the max-depth, and I haven't had time to get back to it. )
but here is a quickie function that is useful.
I am using python to do some quick calculations. I found it easy to
enter the data in "python" format, and use the following function
to load the data. The data looks like this:

( 29, 'Mg-Cl2',     (('Mg', 1, 0.66099e+6),     ('Cl', 2, 0.12413e+7 )))
( 31, 'Ca-S-O4',     (('Ca', 1, 0.11708e+7),     ('S',  1, 0.83657e+6 )))
( 32, 'Mg-S-O4',     (('Mg', 1, 0.41470e+6),  ('S',  1, 0.28843e+6 )))
( 33, 'Ca-Cl2',     (('Ca', 1, 0.64138e+6),  ('Cl', 2, 0.81340e+6 )))
( 34, 'Al2-S-O4',     (('Al', 2, 0.11451e+6 ), ('S',  1, 0.17072e+6 )))
( 35, 'Na2-S-O4',     (('Na', 2, 0.41116e+6 ), ('S',  1, 0.44132e+6 )))
( 36, 'K-H2-P-O4',      (('K',  1, 0.11479e+7 ), ('P',  1, 0.89652e+6 )))
( 37, 'Na4-P2-O7',     (('Na', 4, 0.12013e+7 ), ('P',  2, 0.10849e+7 )))
( 73, 'K-Cl',          (('K',  1, 0.45241e+6),  ('Cl', 1, 0.20116e+6 )))
( 72, 'Ca3-P-O4',     (('Ca', 3, 0.17659e+7),  ('P',  1, 0.70474e+6 )))

And is read into a list with:

>>>f = open( filename, 'r' )
>>>L = []
>>> while 1:
...   n = feval( b )
...   if n = '' :
...     break
...   else:
...     L.append(n)
...


Note:
     It is a snap in python to generate tuple pairs like: ( 'Ca/P', ratio ),
     take a list of those pairs,  invert all of the tuples to:
     ( 'P/Ca', 1.0/ratio ), merge and sort the 2 lists. I'm working on
     the "given any one absolute value, calculate the others from the
     ratio pairs" routine. I just took some time off to read the note
     on classes that is in the 'misc' directory and reorganize it as
     more Obj-Or. I note this mainly to stress how easy to learn the
     language is, and how quickly one can start doing useful work.
     [ As a counter-example, I remember when I first tried to use
       LISP for something other than a textbook exercise, I spent days
       re-inventing functions that were actually in the library, but were
       too obscurely named/indexed/documented to find. ]

Also note: sys.exc_type not in the library reference. I found it with
   dir(sys). Several times I have been ready to write a "why doesn't
   python have" or "why can't you" message, only to find, with a little
   poking around that what I needed *was* there somewhere.


#! /usr/local/python
# (no main - not executable - above is just there for unix 'file' cmd )
#
# feval( file )
# evaluates a line from file
# Intended for loading python formatted data from a file
# Will not work for expressions longer than a line.
# Should modify and make a version that reads multi-line statements
# but 'input' seems to only work on one liners, so this is
# consistent. Should also try a version using a symbol table
# arg to eval. ( i.e.
#            >>> a = 1
#            >>> b = input( '?:' )
#            ?: a
#        Fails: a is not defined within the scope of input()
# unless you also pass a symbol table. )
#

from string import strip
import sys

def feval( File ):
  try:
    line = File.readline()
    if line = '' :  return line ;
    return  eval( strip( line ))
  except EOFError:
    return EOFError
  except  ( TypeError,NameError,RuntimeError), what:
    return ( sys.exc_type, what, strip(line))


########
# note:
# This also works:
# reassign sys.stdin and use the input() function.
# Should probably wrap a try: except: finally: around
# it so it can't terminate without restoring sys.stdin
#

>>> import sys
>>> def infrom( f ):
...    saved = sys.stdin
...    sys.stdin = f
...    tmp = input( `f`+':\n' )
...    sys.stdin = saved
...    return tmp
...
>>> b = open( 'binaries', 'r' )
>>> b = infrom( b )


 - Steve Majewski














Received: by charon.cwi.nl with SMTP; Wed, 4 Dec 1991 23:53:44 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa01338;
          4 Dec 91 17:53 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA02479; Wed, 4 Dec 91 17:45:05 EST
Date: Wed, 4 Dec 91 17:45:05 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: passing/catching a variable number of args in python


Arguments are passed as tuples, except in the case where there is one
or zero arguments.
    f( 1,2,3 )        *is the*         f( (1,2,3) )
        f( 1,2 )        *same as*        f( (1,2) )
                  *BUT*
CASE 1:    f( 1 ) or f( (1) )     *is NOT*    f( 1, ) or f( (1,) )
                    *nor is*
CASE 0:    f( )            *equiv.to*    f( () )

This works to pass a variable number of arguments, except in the
case of NO arguments, which generates an error. Is there any way
around this other than wrapping a try:except: around it to catch
the type error for zero arguments ?


>>> def who( x ):
...   print type( x )
...   if type(x) <> type( () ):  #this takes care of CASE 1
...     x = x,
...   print len(x)
...   print x
...
>>> who( 1,2,3 )
<type 'tuple'>
3
(1, 2, 3)
>>> who( 1, )        # CASE 1:  tuple of len = 1
<type 'tuple'>
1
(1,)
>>> who( 1 )        # CASE 1:
<type 'int'>        # coerced into a tuple.
1
(1,)
>>> who( () )        # CASE 0:
<type 'tuple'>
0
()
>>> who( )
Unhandled exception: type error: function expects argument(s)
Stack backtrace (innermost last):
  File "<stdin>", line 1
  File "<stdin>", line 1


======== "If you have a hammer, find a nail" - George Bush,'91  =========
 Steven D. Majewski        University of Virginia Physiology Dept.
 [e-mail]        Box 449 Health Sciences Center
 Voice: (804)-982-0831        1600 Jefferson Park Avenue
 FAX:   [phone]        Charlottesville, VA 22908










Received: by charon.cwi.nl with SMTP; Fri, 6 Dec 1991 11:37:58 +0100
Received: by voorn.cwi.nl with SMTP; Fri, 6 Dec 1991 10:37:58 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: WHY PYTHON?
In-Reply-To: Your message of "Wed, 04 Dec 91 12:42:08 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 06 Dec 91 11:37:56 +0100
Sender: [e-mail]

>(1) Why the name "python" ?

I an a fan of Monty Python's Flying Circus, and I hate acronyms.  Other than
that, there's nothing deep.

>(2) What role do you see python as fulfilling or in what direction do
>you anticipate its evolution ?
>( Perhaps it *can* be "all things to all people", but I wonder if there
>aren't some potential conflicts ahead between python as:
>   an interactive environment & command interpreter.
>   a command scripting language
>   a general purpose scheme-like symbol processing language
>   a GENERAL purpose high level language for everything else
>   an object oriented language
>   whatever else...
>I see python as potentially good in all these roles, but perhaps
>the needs and priorities differ. An interactive language needs
>conciseness, even if it creates syntactic irregularity. Regularizing
>built-in data types with user-objects, which would seem to be one
>desirable direction, might conflict with adding more built-in's
>( like vectors, for example ) for effeciency. )

I could go on for hours on this subject, but I'll keep it short this time :-)

The one thing that Python definitely does not want to be is a GENERAL purpose
programming language.  Its lack of declarations and general laziness about
compile-time checking is definitely aimed at small-to-medium-sized programs.

As an interactive environment and command interpreter, it leaves a lot to wish
-- the bash history was really a hack to quickily get some kind of line
editing.  I hope I can one day implement a better interactive environment in
Python -- there's a module "python.py" the demo/stdwin directory that shows a
little bit of how much can be done without changing the interpreter.

Object-oriented languages are a means, not a goal in themselves, so, yes,
Python is object-oriented (and more so than most other languages that claim
this adjective) but its goal in life is not to be OO.

I don't know what you mean by symbol-processing language.  If you just mean
non-numerical computations, fine.

Looking in my crystal ball, I think that Python may develop stronger support
for medium-sized programs (e.g., some more compile-time error checking) but
won't lose a bit of its attractiveness for very short programs -- like scripts.

> One issue I will raise ( re: regularizing built-ins and objects ):
> I suggest that hooks to change the print representation of an object
> are desirable. Obviously, for user objects, one can write a '.print'
> method function for the object, and maintain the convention of
> consistently using that name ( or "._print" ). But it would be better
> if you could override "`" (backquote) for both user objects and
> built-in data types. COMMON-LISP has this capability: It comes in
> handy when you are dealing with large vectors/lists/tuples/etc. Instead
> of waiting for your terminal to print out a thousand number, you can
> change the print representation to be something like:
>  "List of size=1024 : ( 0, 1, 2,  ... 1021, 1022, 1023 )"
> Minimally, you should be able to change the string backquote returns.
> Maximally, you should be able to change the action when evaluating a
> symbol, i.e. , currently typing a symbol causes the equivalent to
> 'print `symbol` ' to occur. Instead of:
>   >>> a = [ 1,2,3,4,5 ]
>   >>> a
>   [ 1, 2, 3, 4, 5 ]
> Typing 'a' could cause a plot of the values in a window.
> ( Probably this last is too much, and should be left to a user-level
>   interpreted written on top of python. )
>
> In general, I think that regularization of built-in data types and
> user written objects is a good direction: allow operators like '+' to
> be defined for user-objects, and let built-ins be used as classes for
> inheritance. i.e. "class myList() = list: "

I don't think I agree that the level of modification of existing built-in
operations like you propose is a good thing.

For example, let's take backquotes.  The problem is that not all uses of
backquote are used to write data to the terminal: as long as you don't use any
"weird" objects like files, the string output by `expr` is guaranteed to be a
valid Python expression that evaluates (using eval(), for instance) to an
object with the same value (approximately, in the case of floats).

*If*, and I say *if* there will ever be a mechanism whereby users can modify
built-in object types, I think it will be likely a way to add new methods to
built-in classes.  A way to define standard operators like "+" for user-defined
types (classes) is also quite feasible -- I can imagine that a class can define
methods named _operator_plus, _operator_subscript, and so on (there must then
also be a way to indicate that a class implements a sequence, mapping or
numeric type).

Using built-in classes as base classes for user-defined classes poses several
problems, most of which lie in the realm of implementation.  Several other OO
languages can live without this (C++, Modula-3), so I hope Python can as well.

Thank you for raising these issues,

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Is it a bird? No! Is it a plane? No! It's bicycle repair man!"










Received: by charon.cwi.nl with SMTP; Fri, 6 Dec 1991 11:43:43 +0100
Received: by voorn.cwi.nl with SMTP; Fri, 6 Dec 1991 10:43:42 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: A useful quickie function to read data.
In-Reply-To: Your message of "Wed, 04 Dec 91 13:54:11 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 06 Dec 91 11:43:41 +0100
Sender: [e-mail]

>Also note: sys.exc_type not in the library reference. I found it with
>   dir(sys). Several times I have been ready to write a "why doesn't
>   python have" or "why can't you" message, only to find, with a little
>   poking around that what I needed *was* there somewhere.

Scanning the table-of-contents of the library reference manual is always a
good way to start.  One day I'll prepare a full-blown index...  (But first
the reference manual must be completed.)

># but 'input' seems to only work on one liners,

Actually, input() directly calls the lexical scanner, and accepts a
backslash to indicate continuation lines.

>#            >>> a = 1
>#            >>> b = input( '?:' )
>#            ?: a
>#        Fails: a is not defined within the scope of input()
># unless you also pass a symbol table. )

This example assigns 1 to b if I try it.  The default environment where
input() and eval()/exec() work is that where the call is.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"It's probably pining for the fiords"










Received: by charon.cwi.nl with SMTP; Fri, 6 Dec 1991 14:42:07 +0100
Received: by voorn.cwi.nl with SMTP; Fri, 6 Dec 1991 13:42:06 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: passing/catching a variable number of args in python
In-Reply-To: Your message of "Wed, 04 Dec 91 17:45:05 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 06 Dec 91 14:42:05 +0100
Sender: [e-mail]

>Arguments are passed as tuples, except in the case where there is one
>or zero arguments.

A more appropriate way of saying this is: there is always exactly 0 or 1
argument.  When there appear to be more, there really is a single argument
which happens to be a tuple.  You have more or less discovered this.

The exception for 0 arguments is unfortunate.  I have played with the
thought of making f() and f(()) equivalent, but...  there is a complication
with class methods.  When C is a class defining a method m with argument
list (self, args), and c an instance of C, then calling c.m(x) is equivalent
C.m(c, x).  However, argument-less methods are conventionally defined as
m(self), and here c.m() is equivalent to C.m(c).  If f() and f(()) were to
be equivalent, all argument-less methods would have to be rewritten to
require a second argument, which would always receive the value ().

(Part of all this is caused by the notion that there is *nothing special*
about a method in the way you declare it; purely the fact that a class
attribute happens to be a function object makes it a method.  This
simplifies life in several other places, and gives a nice way of
constructing a class out of existing functions.)

A different approach would appear to *always* make function arguments a
tuple.  This would pass single arguments as singleton tuples, making f(1)
equivalent to f(1,).  However, this doesn't fly: in the current situation,
you can write x = (1,2,3) and later call f(x) with exactly the same result
as f(1,2,3).  In the alternate approach, f(x) would be turned into f(x,),
and would no longer be equivalent to f(1,2,3).  So either way you lose.

Knowing the argument structure of the called function would also be a
possibility, but this definitely has to be done at run-time (when the call
is executed), not at "compile-time" (when it is parsed and turned into
internal opcodes), since there is also a (desirable!) equivalence between

    def f(x):
        a, b = x
        "use a and b"

and

    def f(a, b):
        "use a and b"

So it seems we're stuck.  The most realistic solution in my eyes is to
require methods to always have exactly two arguments, the second one
receiving a dummy () value in case of argument-less methods, but this cannot
be introduced without breaking old code.  (Is there any old code outside my
own that uses this?  I'm always willing to change the language if it breaks
nobody's code but mine -- including the library).

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I'm sorry, is this a five-minute argument, or the full half-hour?"










Replied: Sat, 07 Dec 91 12:43:43 +0100
Replied: [e-mail]
Received: by charon.cwi.nl with SMTP; Fri, 6 Dec 1991 17:24:59 +0100
Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA15756
  (5.65a/IDA-1.4.2 for [e-mail]); Fri, 6 Dec 91 10:19:56 -0600
Return-Path: <[e-mail]>
Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
    id AA01564; Fri, 6 Dec 91 10:19:04 CST
Date: Fri, 6 Dec 91 10:19:04 CST
From: [e-mail] (Daniel LaLiberte)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: passing/catching a variable number of args in python

    A different approach would appear to *always* make function arguments
    a tuple.  This would pass single arguments as singleton tuples, making
    f(1) equivalent to f(1,).  However, this doesn't fly: in the current
    situation, you can write x = (1,2,3) and later call f(x) with exactly
    the same result as f(1,2,3).  In the alternate approach, f(x) would be
    turned into f(x,), and would no longer be equivalent to f(1,2,3).  So
    either way you lose.

You could support calling f(x) by using a separate kind of function call,
analogous to Lisp apply.  f(x) as compared with f(1, 2, 3) really does
a different thing internally, and it was confusing to me as a
new user to discover that these were intended to have the same result.

Maybe you want to consider calling f with arguments being the elements
of the tuple x using the syntax "f x".  Then "f (1, 2, 3)" is really
the same kind of function call as "f x".  This may be inconsistent with other
aspects of the Python syntax; I dont have my grammar handy.

Dan LaLiberte
National Center for Supercomputing Applications

[e-mail]
(Join the League for Programming Freedom: [e-mail])










Received: by charon.cwi.nl with SMTP; Fri, 6 Dec 1991 19:07:06 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa17630;
          6 Dec 91 13:06 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA04610; Fri, 6 Dec 91 12:58:35 EST
Date: Fri, 6 Dec 91 12:58:35 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: WHY PYTHON?

sdm>>
>>One issue I will raise ( re: regularizing built-ins and objects ):
>>I suggest that hooks to change the print representation of an object
>>are desirable. Obviously, for user objects, one can write a '.print'
>>method function for the object, and maintain the convention of
>>consistently using that name ( or "._print" ). But it would be better
>>if you could override "`" (backquote) for both user objects and
>>built-in data types.
>> ...
>>In general, I think that regularization of built-in data types and
>>user written objects is a good direction: allow operators like '+' to
>>be defined for user-objects, and let built-ins be used as classes for
>>inheritance. i.e. "class myList() = list: "

Guido>
>I don't think I agree that the level of modification of existing built-in
>operations like you propose is a good thing.
>
>For example, let's take backquotes.  The problem is that not all uses of
>backquote are used to write data to the terminal: as long as you don't use any
>"weird" objects like files, the string output by `expr` is guaranteed to be a
>valid Python expression that evaluates (using eval(), for instance) to an
>object with the same value (approximately, in the case of floats).
>

After your explaination of the logic behind backquote, I agree that my
proposed change is probably undesirable ( for backquote, that is. )
But if not for "`object`", then maybe for "print thing" ?

>
>*If*, and I say *if* there will ever be a mechanism whereby users can modify
>built-in object types, I think it will be likely a way to add new methods to
>built-in classes. A way to define standard operators like "+" for user-defined
>types (classes) is also quite feasible - I can imagine that a class can define
>methods named _operator_plus, _operator_subscript, and so on (there must then
>also be a way to indicate that a class implements a sequence, mapping or
>numeric type).
>

I prefer (all things being equal) regularity/orthogonality and logical
syntax/semantics in a language because there is less to have to remember.
( Of course I *know* all things are NEVER really equal! )

I can certainly live without these enhancements, or if I really need
them, implement them with my own classes on top of python. But I agree
with what you said about not wanting a dozen different ways of doing
the same thing ( as in perl, for example. I think it just makes it
more confusing to learn. ).

I can make my own classes to duplicate the builtin's: ( and make a
hierarchy: mySequence(), myMutableSeq() = mySequence, myList() =
myMutableSeq(), etc. and give them all .string() methods that
return a print representation. And either do "print thing.string()"
or make a write routine that checks the type or each arg and if
it is an object instance, uses that objects .string() method, else
uses the object itself.
But all this takes maintaining some conventions. I think that is
easier if the language encourages some conventions itself.

One such convention could be that (builtin) print does that checking:
if object instance, check to see it there is a method named
"_PrintRepresentation()" , and if there is, call that to get the
print string.

Note: this would not be necessary if "print" was user re-definable,
but it appears to be a statement, not a function. I don't know any
Modula-3, but I did do some Modula-2 programming at one time, and
I remember that some of the logic behind its design was the fact
that there were things in Pascal that were not implementable *IN*
Pascal for this very reason. ( I'm not convinced that the modula-2
solution was the right one - is that the reason for modula-3 ? )
( Of course in python, "write" is a file method and doesn't have
 the pecularity of "print" )


Guido>
>Using built-in classes as base classes for user-defined classes poses several
>problems, most of which lie in the realm of implementation.  Several other OO
>languages can live without this (C++, Modula-3), so I hope Python can as well.
>

I can "live" with python just the way it is!
I find it much preferable to Perl in both its syntax, modularity and
interactiveness; easier and more high-level than C , and immensely
more powerful that csh/ksh/etc,  although it is not concise enough
to COMPLETELY replace csh, but as I said before, you can't be all
things to all people.

It's only because it is SO good that I sometimes expect it to be
perfect! ( And sometimes I have a wrong idea of what perfect would be. )

These are just minor quibbles.
And if the answer DOES come down to  just developing some coding
and method/class name conventions, then lets discuss THAT now and
develop some example code to ENCOURAGE those conventions.

- Steve











Received: by charon.cwi.nl with SMTP; Fri, 6 Dec 1991 19:55:40 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa20738;
          6 Dec 91 13:55 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA04713; Fri, 6 Dec 91 13:46:55 EST
Date: Fri, 6 Dec 91 13:46:55 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Global variables, assignment, ( & eval )


Re: input()

You are correct.

   >>> a = 1
   >>> b = input( '?:' )
   ?: a
   >>> b
   1

works correctly.

I must have had some other syntax errors and did not
transcribe it correctly. ( In the longer examples I
usually cut & past from the screen so I get it verbatim. )
Sorry.

I'm also sorry because I thought that your reply pointed to
a problem with *my* executable of python, and I thought it
might explain some other behaviour that perplexes me.


I've been having some trouble with global assignment.


./misc/CLASSES :
 "A special quirk of Python is that assignments always go into the
 innermost scope.  Assignments do not copy data -- they just
 bind names to objects.  The same is true for deletions: the statement
 "del x" removes the binding of x from the name space referenced by the
 local scope.  In fact, all operations that introduce new names use the
 local scope: in particularly, import statements and function
 definitions bind the module or function name in the local scope."

 Does this mean that global variables in a module are READONLY.
 That didn't seem to be explicitly stated in the docs. ( Maybe I
 missed it. I looked through some of the demo's and most of the
 globals I saw WERE being used READONLY )

 I guess a quick experiment answers my own question:

>>> N = 1000
>>> def decN():
...   print N
...   N = N - 1
...   print N
...   return N
...
>>> N
1000
>>> decN()
1000
999
999
>>> print N
1000

  ... but I would suggest you stress this a bit more in the tutorial.

Do I have to create a class instance to have a writeable non local variable ?

 ( I mentioned a bug in my du routine - I can't set MAXDEPTH correctly.
   This seems to be it. )


  The following is actually the perplexing part:
  ( The above is not confusing once I did the experiment, but I'm
    not sure I understand the cause of the errors below. Is the
    compiler/interpreter anticipating that since I do an assignment,
    that the references in incK() are to a different K than the
    references in access(), and so the print statement before the
    assignment give me an error ?
    Could you perhaps give us a bit more on binding & scope of
    variables, etc. ?  )


# module test
#
N = 99
S = 'This is a test: '
K = 1

def access():
  print N, S, K
  return ( N, S, K )

def newK(x):
  K = x
  return K

def decN():
  print N
  N = N - 1
  return N

def incK():
  print K
  K = K + 1
  return K



>>> import test
>>> test.K
1
>>> test.access()
99 This is a test:  1
(99, 'This is a test: ', 1)
>>> test.newK( 33 )
33
>>> test.access()
99 This is a test:  1
(99, 'This is a test: ', 1)
>>> test.K
1
>>> test.incK()
Unhandled exception: undefined name: K
Stack backtrace (innermost last):
  File "<stdin>", line 1
  File "./test.py", line 21
    print K
>>> K = 3        # just to check that it is not GLOBAL/global
>>> test.incK()
Unhandled exception: undefined name: K
Stack backtrace (innermost last):
  File "<stdin>", line 1
  File "./test.py", line 21
    print K




======== "If you have a hammer, find a nail" - George Bush,'91  =========
 Steven D. Majewski        University of Virginia Physiology Dept.
 [e-mail]        Box 449 Health Sciences Center
 Voice: (804)-982-0831        1600 Jefferson Park Avenue
 FAX:   [phone]        Charlottesville, VA 22908










Replied: Sat, 07 Dec 91 12:18:55 +0100
Replied: [e-mail]
Received: by charon.cwi.nl with SMTP; Fri, 6 Dec 1991 20:40:00 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa23622;
          6 Dec 91 14:39 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA04791; Fri, 6 Dec 91 14:31:14 EST
Date: Fri, 6 Dec 91 14:31:14 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Last message ( Scope & globals & binding )


That was probably an incorrect statement to say that globals are
READONLY.  The problems is not with globals but with assignment.
i.e. One reason this wasn't clear sooner was that I did not run
into this problem with globals that were LISTS because I did not
assign to them, but used the access method .append(). So therefore
global LISTS were updated correctly.
I used assignment for scalars.

Classes, BTW, do work:

class Global():
  pass

G = Global()
G.k = 1000

def decK():
  G.k = G.k - 1
  return G.k

... etc...
Works as an assignable global variable.

Alternately, scalars could be one element lists, and assignment
done with replacement of the list element.
( Or put all (module wide) globals into a dictionary and replace
  the values ? - I haven't tried that yet. )

Possibly my problems originated with a poor design in the first place -
( Stuffing things into globals was a quick hack to test an additional
  feature. ) But I do think those issues DO need to be made clear(er)
 in the user-guide. Reading the misc/CLASSES doc helped, but I don't
 think the logic is explicitly spelled out in the user guide.

- Steve










Received: by charon.cwi.nl with SMTP; Sat, 7 Dec 1991 00:29:55 +0100
Received: by mcsun.EU.net via EUnet;
    id AA25800 (5.65a/CWI-2.128); Sat, 7 Dec 1991 00:29:54 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA06367; Fri, 6 Dec 91 18:22:38 -0500
Received: from sparky.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 182126.17180; Fri, 6 Dec 1991 18:21:26 EST
Received: by sparky.IMD.Sterling.COM (4.1/smail2.5/04-08-90)
    id AA05133; Fri, 6 Dec 91 17:22:18 CST
From: [e-mail] (Richard Ohnemus)
Message-Id: <[e-mail]>
Subject: Please add me to mailing list
To: [e-mail]
Date: Fri, 6 Dec 91 17:22:18 CST
X-Mailer: ELM [version 2.3 PL2]

Please add me to the python mailing list. Thanks...
--
Rick Ohnemus   INTERNET: [e-mail]   UUCP: uunet!sparky!rick
LAND: Sterling Software IMD, 1404 Ft. Crook Rd. South, Bellevue NE. 68005-2969
Phone: [phone]        FAX: [phone]
I never receive credit for anything I write! (I'm an Ohnemus. 8-)










Received: by charon.cwi.nl with SMTP; Sat, 7 Dec 1991 12:18:55 +0100
Received: by voorn.cwi.nl with SMTP; Sat, 7 Dec 1991 11:18:54 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Last message ( Scope & globals & binding )
In-Reply-To: Your message of "Fri, 06 Dec 91 14:31:14 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Sat, 07 Dec 91 12:18:53 +0100
Sender: [e-mail]

"Steven D. Majewski" <[e-mail]> writes:
>That was probably an incorrect statement to say that globals are
>READONLY.  The problems is not with globals but with assignment.
(etc.)

You are figuring out the obscure parts of Python at an amazing
speed...  You actually discovered something that I can't explain!
Indeed the documentation isn't very clear about globals except for
that one passage in misc/CLASSES.

The *real* *deep* reason why there is no global assignment is that
there is no static symbol table listing all names of known local and
global variables (really "name bindings" in the standard jargon that
I'm trying to establish for discussing these issues).  If the
interpreter encounters a statement "x = 1" it has no idea whether
there is a global x this might refer to, so the assignment is always
made local.  If there is *already* a global by this name it is
possible to find out (by just looking it up in the global name space),
but this would still prohibit creating new globals from within a
function.  I also thought that local variables would be in the
majority, and disliked the possibility that using a local variable
like "i" would accidentally clash with a global also named "i".
Therefore I decided that all variable assignments were to be local.

Variable references don't face the same problems, so they use a
local-scope-first rule; read-only acces to globals is essential
because (most) functions and imported modules are global name bindings.

The code generator (which didn't exist in very early versions of
Python) adds a little subtlety: it actually builds a list of local
variables by finding all name binding statements, and then generates
code that uses this fact throughout the function, distinguishing
between local and global lookups.  (The reason for this, BTW, is to
speed up global name lookups so that they don't first have to miss in
the local name set.)  This explains your incK() errors.  I was
surprised that this didn't break your earlier decN() example;
apparently the code generator generates different code, that uses the
old local-before-global rule when the global scope is the user's
workspace.  (Another way to trigger this is to write from
<some-module> import *; here the compiler can't figure out what the
local names will be.  But I think it's a bug here.)

You're right that a way of faking global variables is to lock them all
up in a class instance, and there are several demo programs that use
this trick (e.g., mclock).  Object-oriented design can usually avoid
the need for global variables in the first place.

But I still think that for simple programs the global variable
assignment has the merit of simplicity and relative elegance, and
actually I am thinking about introducing a 'global' statement with
which you can declare that names you are using in a function are
actually references to globals.  This statement would be placed
inside the function body that uses the globals.  Python's main source
of inspiration, ABC, has a similar statement (SHARE), and I think I
saw it in one of its competitors (Tcl) as well.  (What's Perl's
attitude towards locals and globals?  I forgot...)

BTW, the user's workspace is not super-global.  (Module 'builtin',
containing the built-in functions and exceptions, is.)  If you really
need to access the user's workspace from a module, import __main__.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Well I'm a plumber.  I can't act"










Received: by charon.cwi.nl with SMTP; Sat, 7 Dec 1991 12:43:43 +0100
Received: by voorn.cwi.nl with SMTP; Sat, 7 Dec 1991 11:43:42 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: passing/catching a variable number of args in python
In-Reply-To: Your message of "Fri, 06 Dec 91 10:19:04 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Sat, 07 Dec 91 12:43:41 +0100
Sender: [e-mail]

>You could support calling f(x) by using a separate kind of function call,
>analogous to Lisp apply.  f(x) as compared with f(1, 2, 3) really does
>a different thing internally, and it was confusing to me as a
>new user to discover that these were intended to have the same result.

Erm, I don't understand what you mean by "really does a different
thing internally".  In my mind they do very different things.  In the
second case f is called with the expression-list "1, 2, 3" as
argument, which has the same value as x (which was assigned "1, 2, 3"
a line earlier).  Maybe you can explain what you felt again?

I believe that the equivalence is actually quite useful, and used
often enough that a special "apply" function would cripple the
language.  Take, for instance, a simple "plot" function that takes a
point as argument.  I can either write plot(x, y) or plot(p), assuming
p is a tuple of "x, y" coordinates, and I don't have to know whether
the function was declared with one (point) or with two (coordinate)
arguments.  Using your proposal (if I understand it well), I would
have to write f(p[0], p[1]) if it was declared as f(x, y), or I would
have to call it as f((x, y)) if it was declared as f(p).  Currently,
in Python, there is an informal rule that says "placing extra
parentheses never hurts".

Of course, all this makes Python's argument passing *very* different
from other languages (except ABC), which may be the reason why so many
people have difficulties with it -- either initially, or eternally.
The eternally case worries me most, if it exists, but the initially
case is also a reason to worry, since it makes Python harder to learn,
whicl easy-to-learn is one of its big advantages.

*** Question to the general audience: is this serious enough to
warrant changing the language (and potentially lots of existing code)?

>Maybe you want to consider calling f with arguments being the elements
>of the tuple x using the syntax "f x".  Then "f (1, 2, 3)" is really
>the same kind of function call as "f x".  This may be inconsistent with other
>aspects of the Python syntax; I dont have my grammar handy.

This was used in ABC, but it would be inconsistent in Python (assuming
no other syntax changes).  For example, it would render x[y] ambiguous:
is it a subscription of list/table x with index/key y, or is it a call
of function x with argument [y] (a list containing one element, y)?
Also, function calls without arguments would be impossible -- just "f"
doesn't call the function f but yields the function object f.  (This
isn't a problem in ABC since ABC has no function variables.)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"It's funny, isn't it?  How your best friend can just blow up like that?
I mean, you wouldn't think it was medically possible, would you?"










To: [e-mail]
Subject: Why print is a built-in statement
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Sat, 07 Dec 91 15:00:00 +0100
--------
Steven Majewski mentioned one issue that I didn't address yet: why
"print" is built-in in Python.  I'd like to explain this.

One of the reasons is that a simple print statement is useful for
simple programs.  Being a statement it doesn't need parentheses around
its argument list, which saves some typing.

Another reason is that it treats arguments separated by commas
differently than a single argument consisting of a tuple:

    print 'x =', x

might print

    x = 3.14

while

    t = 'x =', x
    print t

would print

    ('x =', 3.14)

(This has to do with the function argument discussion, by the way.)

The third reason has to do with the final linefeed written by print:
again, for simple programs, it's desirable that the simplest form of
print statement prints a complete line; but there also must be a way
to print partial lines.  Using special syntax (a trailing comma) to
specify the alternate behavior seemed preferable over having two
functions like Pascal's write and writeln (especially since it would
have meant two reserved words given the choice for non-function
syntax).

Writing it down makes it all sound like feeble excuses for a real
solution; but everything else I could think of had other
disadvantages.  Perhaps printing is one of these things that are
important enough to warrant more than one way to do things, even in
Python...

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"*Nobody* expects the Spanish Inquisition"










Replied: Sun, 08 Dec 91 01:44:03 +0100
Replied: [e-mail]
Received: by charon.cwi.nl with SMTP; Sun, 8 Dec 1991 01:09:10 +0100
Received: from juno (juno.ericsson.se) by mailgate.ericsson.se (4.1/SMI-4.1-MAILGATE1.7)
    id AA07412; Sun, 8 Dec 91 01:09:05 +0100
Received: from juno21.ericsson.se by juno (4.1/SMI-4.1-LME1.6)
    id AA07694; Sun, 8 Dec 91 01:09:01 +0100
Received: by juno21.ericsson.se (4.1/client-1.3)
    id AA16478; Sun, 8 Dec 91 01:08:59 +0100
Date: Sun, 8 Dec 91 01:08:59 +0100
From: Mats Lidell TM/JUF 91753 <[e-mail]>
Message-Id: <[e-mail]>
To: Guido van Rossum <[e-mail]>
Cc: [e-mail]
Subject: Re: WHY PYTHON?
References: <[e-mail]>
    <[e-mail]>

>>>>> "Guido" == Guido van Rossum <[e-mail]> writes:

  Guido> Using built-in classes as base classes for user-defined
  Guido> classes poses several problems, most of which lie in the
  Guido> realm of implementation.  Several other OO languages can live
  Guido> without this (C++, Modula-3), so I hope Python can as well.

The difficulties in the implementation doesn't mean much to the user
:-)

One promising thing with OO is that you can keep the name space small.
If you could build new types from the builtin the chance of
preserving the same name for similar operations would be greater.

A promising thing with small languages is that you don't have to learn
a lot of special purpose mumbo jumbo. This seems to be a good thing
for a script language since you'r not likely to use it everyday. But
the language also needs to have enough power so you'll easily express
what you want.  The OO-things can give you more specialized powerful
objects which might still be used in the same way as builtin objects.
If that's possible you have won a part of the battle of complexity.
Overloading builtin operations can be viewed in the same light. If
adding two objects make sense then maybe "+" is a good way to express
that.

These things are contradictory but I'll suggest keeping the smallness
in favor for adding more power with special constructs. Treating the
builtin types just as user defined wouldn't it make the language
smaller and easier to comprehend?

Another convenient thing for a script language would be to have
unbound precision integer arithmetic.

Yours
%% Mats Lidell
[e-mail]
"A man about to speak the truth should keep one foot in the stirrup."
-- Old Mongolian Saying










Received: by charon.cwi.nl with SMTP; Sun, 8 Dec 1991 01:44:03 +0100
Received: by voorn.cwi.nl with SMTP; Sun, 8 Dec 1991 00:44:02 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: WHY PYTHON?
In-Reply-To: Your message of "Sun, 08 Dec 91 01:08:59 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Sun, 08 Dec 91 01:44:02 +0100
Sender: [e-mail]

Mats Lidell writes:
>Another convenient thing for a script language would be to have
>unbound precision integer arithmetic.

Python has this, just append 'L' to your numeric constants.  It isn't
default because it is slower than ordinary integers, and I like to
keep Python reasonably efficient whenever possible.  (If you look real
careful, the language is full of places where speed was a design
criterion, even if it was rarely the only one.)

BTW, Python is not just a script language!  If all you need is
scripts, Tcl would be a better choice.  Python is a real programming
language, but concise enough to use for ad-hoc programming such as
scripts.  When you write your scripts in Python, you don't have to
recode them in a real language when they get larger.  Python is really
sitting halfway between script languages like sh and compiled language
like C.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Wenn ist das Nunnstueck git und Slotermeyer?"
"Ja! Beierhund das oder die flipperwaldt gersput."










Received: by charon.cwi.nl with SMTP; Sun, 8 Dec 1991 17:16:03 +0100
Received: by schelvis.cwi.nl with SMTP; Sun, 8 Dec 91 17:16:02 +0100
Message-Id: <[e-mail]>
To: Guido van Rossum <[e-mail]>
Cc: [e-mail]
Subject: Re: passing/catching a variable number of args in python
In-Reply-To: Message by Guido van Rossum <[e-mail]> ,
         Sat, 07 Dec 91 12:43:41 +0100 , <[e-mail]>
Organisation: AMOEBA project, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone](home)
X-Last-Band-Seen: Maroon town, Boter Ska en Eieren (Melkweg, 8-12)
X-Mini-Review: Party-ska!
Date: Sun, 08 Dec 91 17:16:01 +0100
From: [e-mail]

The only things that took me some time to work out (with Guido's help)
with the parameter passing were the fact the the first argument of a
method was funny, so you have to use constructs like
def func(self,(foo,bar))
in some places. The other thing was the funny difference between
zero-, one- and many-argument functions (although this might be more
due to the handling of 1-sized tuples than anything else).
--
Jack Jansen        | In Holland things are serious, but never hopeless.
[e-mail] | In Ireland things are hopeless, but never serious.
uunet!cwi.nl!jack   G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Replied: Mon, 09 Dec 91 10:54:55 +0100
Replied: [e-mail]
Received: by charon.cwi.nl with SMTP; Sun, 8 Dec 1991 23:46:27 +0100
Received: from juno (juno.ericsson.se) by mailgate.ericsson.se (4.1/SMI-4.1-MAILGATE1.7)
    id AA09610; Sun, 8 Dec 91 23:46:26 +0100
Received: from juno21.ericsson.se by juno (4.1/SMI-4.1-LME1.6)
    id AA00772; Sun, 8 Dec 91 23:46:22 +0100
Received: by juno21.ericsson.se (4.1/client-1.3)
    id AA22744; Sun, 8 Dec 91 23:46:20 +0100
Date: Sun, 8 Dec 91 23:46:20 +0100
From: Mats Lidell TM/JUF 91753 <[e-mail]>
Message-Id: <[e-mail]>
To: Guido van Rossum <[e-mail]>
Cc: [e-mail]
Subject: Re: WHY PYTHON?
References: <[e-mail]>
    <[e-mail]>

I said:
>Another convenient thing for a script language would be to have
>unbound precision integer arithmetic.

Guido said:
  Guido> Python has this, just append 'L' to your numeric constants.

Hup... I better get me a newer version of python! Sorry :-)

Since Python is the first real OO prototyping language I have come
across I must ask the following:

In an OO prototyping language, OOPL (?), the natural language to
connect to wouldn't be C but C++. A OOPL object could then be a thin
wrapper around the C++ object and of course you would like to be able
to make C++ code access OOPL objects as well.  Does anybody know of
some work in this direction? (Is it to weird to consider or is it in
Python already? :-))

Yours
%% Mats Lidell
[e-mail]
"Only a mediocre person is always at his best."
-- W. Somerset Maugham










Received: by charon.cwi.nl with SMTP; Mon, 9 Dec 1991 09:00:35 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa12787;
          9 Dec 91 3:00 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA10178; Mon, 9 Dec 91 02:51:48 EST
Date: Mon, 9 Dec 91 02:51:48 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: passing/catching a variable number of args in python
Cc: [e-mail]


I think this argument passing business is something I will want to
mull over a while before giving you my considered opinion.

BUT, my unconsidered opinion, right now, is that I approve of you
compromise. I don't think having two cases ( zero or one arg ) to
deal with is too big a trade considering the flexibility you get
with the tuple equivalence.

I *don't* think breaking code should be a major consideration right now.
( But then I am the proud author of exactly ONE peice of python code ;-)
One reason for bringing up these issues is that you are at release 0.92
and might as well have all the syntactic shake-outs BEFORE you get to
1.0 . At that point you should consider the major feature cast in stone,
but we will forgive you up till then.

I *didn't* thin the logic of the zero-or-one/tuple-equivalence passing
mechanism was difficult to figure out, and your answer was more or less
what I expected, but I thought it would be a good topic for discussion.

I think zero-or-one is only important in one direction, i.e. the typical
case is a procedure that expects ONE arg and is called with NONE.
How about making argument mismatches a non-error.
Where there are too few dummy args, they get packed as a tuple in the last
arg ( I believe that IS the current action ? )
Where there are too few dummy args, the value 'None" becomes the arg. value.
( I don't know how "None" is represented, so I don't know if that is
practical. )

But if there is no clear winning compromise, I can live with things as they
are. But, perhaps the exception namespace should be a little finer so we
can just catch and only catch some "common" error ( like no arg when one
expected! )

For that, I propose that the semantics be modified so that exception tuples
are effectively "flattened". This will allow a hierarchy in the exception
namespace ( less or more specific ). e.g.
  SyntaxError = ( several different types of syntax error )
  TypeError = ( several different types of type error )

  try:
     ...
  except ( SyntaxError, aSpecificTypeError ):

  and the above is effectively the same as
  except ( SyntaxErr-1, SyntaxErr-2, ... SyntaxErr-N, aSpecificTypeError ):

Exception signal mechanism's in VMS (for example) and ( I think ) in some
other languages that support exceptions, catch ALL of the appropriate
signals, and give the user-exception processing code the responsibility of
filtering them. There is a "resignal" mechanism is VMS to pass the
exception down to the next level of processing.
This would be equivalent to python code checking the exception argument to
see if it was the one it was expecting, and if not, raising that exception
again, so that some outer code could have a chance of catching it. ( Or of
giving an error message - too general exception classes may have the
effect of masking errors that the user didn't anticipate. That is REALLY
what I'm concerned about! )


Forgive me for not trying out and including some better examples and for
being a bit too verbose for my own good. I'm writing this at home,
( without the Python manual at my side ) and editing on the modem
can be a chore.

If it wasn't 2AM, I would edit this down to two separate messages:
argument passing & exceptions.

- Steve











Received: by charon.cwi.nl with SMTP; Mon, 9 Dec 1991 09:56:38 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa14509;
          9 Dec 91 3:56 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA10196; Mon, 9 Dec 91 03:48:03 EST
Date: Mon, 9 Dec 91 03:48:03 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Last message ( Scope & globals & binding )
Cc: [e-mail]

> From [e-mail] Sat Dec  7 06:10:51 1991
>
> You are figuring out the obscure parts of Python at an amazing
> speed...  You actually discovered something that I can't explain!
> Indeed the documentation isn't very clear about globals except for
> that one passage in misc/CLASSES.
>
> ...
>
>      I also thought that local variables would be in the
> majority, and disliked the possibility that using a local variable
> like "i" would accidentally clash with a global also named "i".
> Therefore I decided that all variable assignments were to be local.
>
> ...
>
> You're right that a way of faking global variables is to lock them all
> up in a class instance, and there are several demo programs that use
> this trick (e.g., mclock).  Object-oriented design can usually avoid
> the need for global variables in the first place.
>
> But I still think that for simple programs the global variable
> assignment has the merit of simplicity and relative elegance, and
> actually I am thinking about introducing a 'global' statement with
> which you can declare that names you are using in a function are
> actually references to globals.  This statement would be placed
> inside the function body that uses the globals.  Python's main source
> of inspiration, ABC, has a similar statement (SHARE), and I think I
> saw it in one of its competitors (Tcl) as well.  (What's Perl's
> attitude towards locals and globals?  I forgot...)
>

I agree that for a language that will be used for quick programs
( and quick fixes/kludges ) globals are probably essential.

The problem wasn't hard to find. ( Or maybe I should say the problem
wasn't hard to GENERATE - I did have a little trouble FINDING it. )
I was just throwing in one of those quick kludges and adding a global
variable was quicker than rethinking the module interfaces.

However, the process of fixing it ( my program ) left me a bit ambivalent.
I an definitely not a proponent of "straight-jacket" program languages
that make it impossible to do many things in order to keep you from
doing ONE BAD thing. But I'm not against a language that somwhow has
features that encourage you to write GOOD code.

The first fix was that I wrote my globals with "class Global(): pass"
null classes. However, once I got the original to work, I was drawn
to try to OO it a bit more.
I had globals: initial_depth, max_depth and local current_depth, plus
function dir_depth ( just counted the number of "/" in a pathname ).
I now have a half-asses OO version that was just bad enough to show
me the RIGHT way to do it. So I found trying to do without globals
a good learning experience. But probably not one I want to experience
when I'm in a big hurry to "get the damn thing working!"

Anyway:
 "global a = 0"
 "global b,c "
Can easily be the syntactic shorthand for:
 Class __Global__():
    pass
 __global__ = __Global__()
 __global__.a = 0
 __global__.b =
 __global__.c =

 Global to the current module of course.
 But access to module.a would be equivalent to module.__global__.a
 [ I am here assuming an addition to the symbol table search path. ]

 [ BTW Guido - have you ever looked at FORTH dictionaries ?
   The syntax of alternate namespaces is awkward in FORTH, but
   the dictionaries are tree structured, with the search going
   backward from the local leaves to the root ( with side trips
   programmable ) so the use of the dictionary search order is
   the primary way of managing the namespace. ]


 What to do with b,c - that's the rub. Ideally, we would like to
 catch the error of access of uninitialized variables. i.e. using
 the global value 'b' before an assignment to b should be signaled.
 Is there an easy way for it to be know to be a global name and yet
 be unbound ?

 - Steve

( Again: sorry about the lack of discipline due to the late hour and
  a slow modem at home. I meant to indicate that I agreed with the
  comment I included above: preponderence of local ref. over global
 and of global read ref. over global write ref. , etc. )

======== "If you have a hammer, find a nail" - George Bush,'91  =========
 Steven D. Majewski        University of Virginia Physiology Dept.
 [e-mail]        Box 449 Health Sciences Center
 Voice: (804)-982-0831        1600 Jefferson Park Avenue
 FAX:   [phone]        Charlottesville, VA 22908










Received: by charon.cwi.nl with SMTP; Mon, 9 Dec 1991 10:54:57 +0100
Received: by voorn.cwi.nl with SMTP; Mon, 9 Dec 1991 09:54:54 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: WHY PYTHON?
In-Reply-To: Your message of "Sun, 08 Dec 91 23:46:20 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 09 Dec 91 10:54:53 +0100
Sender: [e-mail]

Mats Lidell writes:
>In an OO prototyping language, OOPL (?), the natural language to
>connect to wouldn't be C but C++. A OOPL object could then be a thin
>wrapper around the C++ object and of course you would like to be able
>to make C++ code access OOPL objects as well.

If all OO languages were the more or less equivalent except for minor
syntactic issues, this would be a reqsonable assumption.  However, as
it is, this would make the OO model of the wrapper basically the same
as that of the language it is wrapping.  I don't think you would want
Python's OO mechanisms too tightly bound to those of C++.

While the same reasoning could be applied to Python's reliance on C
for its non-OO features, I believe that at least the features from C
that I have borrowed for Python are much less controversial.

But the true reason why Python isn't based on C++ is of course
availability -- requiring C++ would initially restrict Python's
popularity mostly to the C++ community, for very practical reasons
like the availability of C++ compilers (and there is a lot of
incompatibility in that world as well!).

>Does anybody know of
>some work in this direction? (Is it to weird to consider or is it in
>Python already? :-))

There's no reason why some extension modules of Python couldn't be
written using C++, but of course this isn't the same as what you proposed.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"That was never five minutes just now!"
"I'm afraid it was."










Replied: Mon, 09 Dec 91 18:53:05 +0100
Replied: [e-mail]
Received: by charon.cwi.nl with SMTP; Mon, 9 Dec 1991 18:14:27 +0100
Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA22928
  (5.65a/IDA-1.4.2 for [e-mail]); Mon, 9 Dec 91 11:09:13 -0600
Return-Path: <[e-mail]>
Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
    id AA04145; Mon, 9 Dec 91 11:07:28 CST
Date: Mon, 9 Dec 91 11:07:28 CST
From: [e-mail] (Daniel LaLiberte)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: passing/catching a variable number of args in python

I dont think optional or rest args (in Lisp terminology) would work
well in Python, at least not with the current mechanism of redistributing
actual arguments to fit formal arguments.  This brings up the issue of
ambiguous situations.  What if function f takes three arguments, a, b, c,
and is given two arguments (1, 2) and (3, 4)?  Do a and b get 1 and 2
leaving c with (3, 4), or does a get (1, 2) while b and c get 3 and 4?
Whichever way it works, what if the user wants to do it the other way?

    >f(x) as compared with f(1, 2, 3) really does
    >a different thing internally, and it was confusing to me as a
    >new user to discover that these were intended to have the same result.

    Erm, I don't understand what you mean by "really does a different
    thing internally".

Well, the user is supposed to not be concerned about whether separate
arguments are required, and so the two calls are semantically equivalent
since they result in the same thing, but to do the "same thing" in each
case, they have to do different things internally.

    Using your proposal (if I understand it well), I would
    have to write f(p[0], p[1]) if it was declared as f(x, y), or I would
    have to call it as f((x, y)) if it was declared as f(p).  Currently,
    in Python, there is an informal rule that says "placing extra
    parentheses never hurts".

I don't think calling f((x, y)) would be as annoying as f(p[0], p[1]),
so people would tend to declare the function with f(p) if it is meaningful
to collect x and y into one argument, and then if the function writer
wanted to break out the parts of p, the assignment x, y = p does the job.
Perhaps the same ambiguity I mentioned above exists in assignments..?

Alternatively, the function could be declared f((x, y)).  Analogously, the
assignment above should be done like (x, y) = p.  ML and probably
other languages have this kind of pattern-matching/argument-parsing
mechanism developed to a fine art.

    *** Question to the general audience: is this serious enough to
    warrant changing the language (and potentially lots of existing code)?

I think you need to think more about the ambiguous cases as well as user
confusion.

    >Maybe you want to consider calling f with arguments being the elements
    >of the tuple x using the syntax "f x".  Then "f (1, 2, 3)" is really
    >the same kind of function call as "f x".

    This was used in ABC, but it would be inconsistent in Python (assuming
    no other syntax changes).  For example, it would render x[y] ambiguous:

How about if x is a function object, then x[y] does a function call
with list [y] as argument.  Or if x is a list or table, then x[y] does the
subscription with index/key y.  You couldn't tell until run time which
it would be since the type of x is not declared, but the ambiguity would
be resolved.

    Also, function calls without arguments would be impossible

Yes this is still a problem.  I prefer the ML-like pattern matching in
any case.


Dan LaLiberte
National Center for Supercomputing Applications

[e-mail]
(Join the League for Programming Freedom: [e-mail])










Replied: Mon, 09 Dec 91 19:14:23 +0100
Replied: [e-mail]
Received: by charon.cwi.nl with SMTP; Mon, 9 Dec 1991 18:25:01 +0100
Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA23797
  (5.65a/IDA-1.4.2 for [e-mail]); Mon, 9 Dec 91 11:19:53 -0600
Return-Path: <[e-mail]>
Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
    id AA04476; Mon, 9 Dec 91 11:18:59 CST
Date: Mon, 9 Dec 91 11:18:59 CST
From: [e-mail] (Daniel LaLiberte)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Other Python syntax changes

Other issues I have been considering from time to time...

I'd like to see optional static typing, perhaps of the ML kind.
Although lack of type declarations is useful during prototyping, I like
to use type declarations even then to have the compiler make sure that
I am being consistent.  Maybe declarations should take the form of
general assertions so they may be used throughout code for more general
consistency checks.

Also, I would like to see an optional alternate block structuring
syntax that doesnt rely on indenting and line termination.  Russell has
this, I believe.  There are problems with portability of source code
between editors with different tabsize defaults.  Also, it inhibits
automatic code generation since indenting must be accounted for.

Related to this, I like Lisp's representation of functions with Lisp
data structures, so you can look at them, and modify them.  Whatever
this representation is for Python, one should be able to enter a function
using constructors for the same data structures (e.g. (def, func, (args) ...)).

Dan LaLiberte
National Center for Supercomputing Applications

[e-mail]
(Join the League for Programming Freedom: [e-mail])










Received: by charon.cwi.nl with SMTP; Mon, 9 Dec 1991 18:53:05 +0100
Received: by voorn.cwi.nl with SMTP; Mon, 9 Dec 1991 17:53:05 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: passing/catching a variable number of args in python
In-Reply-To: Your message of "Mon, 09 Dec 91 11:07:28 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 09 Dec 91 18:53:04 +0100
Sender: [e-mail]

Daniel LaLiberte writes:
>I dont think optional or rest args (in Lisp terminology) would work
>well in Python, at least not with the current mechanism of redistributing
>actual arguments to fit formal arguments.

There is no such mechanism.  Functions either have no argument or
they have one argument.  The syntax for one argument allows a
comma-separated list of expressions, which builds a tuple; it is this
tuple value that becomes the *single* argument to the function.  When
the function is actually declared with multiple arguments, it expects
a tuple and unpacks this into the respective arguments, just like an
unpacking assignment.

>This brings up the issue of
>ambiguous situations.  What if function f takes three arguments, a, b, c,
>and is given two arguments (1, 2) and (3, 4)?  Do a and b get 1 and 2
>leaving c with (3, 4), or does a get (1, 2) while b and c get 3 and 4?
>Whichever way it works, what if the user wants to do it the other way?

There is no ambiguity.  This is a run-time error (detected in the
called function), similar in nature to the error in assignments like
"a, b = 1, 2, 3".

(This is Daniel:)
>    >f(x) as compared with f(1, 2, 3) really does
>    >a different thing internally, and it was confusing to me as a
>    >new user to discover that these were intended to have the same result.
(my reply:)
>    Erm, I don't understand what you mean by "really does a different
>    thing internally".
(Daniel again:)
>Well, the user is supposed to not be concerned about whether separate
>arguments are required, and so the two calls are semantically equivalent
>since they result in the same thing, but to do the "same thing" in each
>case, they have to do different things internally.

I still maintain nothing is done differently.  Maybe my explanation
above (1-or-1 argumet) explains your confusion?

>Alternatively, the function could be declared f((x, y)).  Analogously, the
>assignment above should be done like (x, y) = p.  ML and probably
>other languages have this kind of pattern-matching/argument-parsing
>mechanism developed to a fine art.

Isn't Python's mechanism very similar (although probably implemented
totally different), except that extra parentheses don't count?  After
all, you can define a function as follows

    def f(a, (b, c, d), (e, (f, g))): ...

and call it in either of the following ways:

    f(a, (b, c, d), (e, (f, g)))
    bcd = b, c, d
    fg = f, g
    f(a, bcd, (e, fg))
    efg = e, fg
    f(a, bcd, efg)
    abcdefg = a, bcd, efg
    f(abcdefg)

(But I admit I don't know even a little bit of ML.)

>How about if x is a function object, then x[y] does a function call
>with list [y] as argument.  Or if x is a list or table, then x[y] does the
>subscription with index/key y.

I have the feeling that this is something which should be unambigous
at compile time (at least in a computer language -- in natural
languages this kind of things happens all the time).  [If you still
disagree I'm willing to go into an argument off-line; I have a feeling
this is different from using '+' for strings and numbers, but it takes
too long to explain why I think that is so.]

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I'm sorry, is this a five-minute argument, or the full half-hour?"










Received: by charon.cwi.nl with SMTP; Mon, 9 Dec 1991 19:14:24 +0100
Received: by voorn.cwi.nl with SMTP; Mon, 9 Dec 1991 18:14:23 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Other Python syntax changes
In-Reply-To: Your message of "Mon, 09 Dec 91 11:18:59 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 09 Dec 91 19:14:22 +0100
Sender: [e-mail]

Daniel LaLiberte writes:

>I'd like to see optional static typing, perhaps of the ML kind.
>Although lack of type declarations is useful during prototyping, I like
>to use type declarations even then to have the compiler make sure that
>I am being consistent.  Maybe declarations should take the form of
>general assertions so they may be used throughout code for more general
>consistency checks.

Wouldn't you like it if the compiler could figure out that you were
being inconsistent even without type declarations?  This is the kind
of static checking present in ABC, and I'd like to introduce it in
Python as well -- eventually.  I know there are problems implementing
this in Python (for ABC it's solved), but I know *I* would like the
resulting system, if it were ever built, better than one which
required me to supply type declarations that are obvious from the
context...

>Also, I would like to see an optional alternate block structuring
>syntax that doesnt rely on indenting and line termination.  Russell has
>this, I believe.  There are problems with portability of source code
>between editors with different tabsize defaults.

I don't care much for this personally (even though about half of all
Python development happens in an editor with 4-space tab stops for
default), but I've heard the complaint before.  Maybe someone on the
list could write up a solid proposal?

>Also, it inhibits
>automatic code generation since indenting must be accounted for.

(I presume you mean generating Python statements on the fly for exec()
etc.)  In fact it is very easy to increase the indentation of a piece
of code by just inserting a tab at the beginning of each line.

>Related to this, I like Lisp's representation of functions with Lisp
>data structures, so you can look at them, and modify them.  Whatever
>this representation is for Python, one should be able to enter a function
>using constructors for the same data structures (e.g. (def, func, (args) ...))

You can inspect the generated (virtual machine) code of a function or
module, but you can't change it since it is represented as immutable
objects.  The standard modules "dis.py" and "tb.py" use this --
"dis" disassembles the generated code, which is useful for debugging
the code generator, and "tb" allows inspection of the stack trace
after a program has died.  (I should really document this one...)

But I'd like to hide this representation from most users, so it can be
changed if the needs of the parser, code generator and static tester
change.  In Lisp, the representation of the parse tree is pretty
obvious, given its lack of syntax; in Python, however, the parser has
a lot of freedom.  I don't believe there is in general much need for
self-modifying programs of the kind that Lisp allows; most practical
applications of it (such as on-the-fly code generation) are possible
in Python using eval() and exec() without the need to ever peek or
poke around in function objects.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"It's probably pining for the fiords"










Replied: Tue, 10 Dec 91 11:38:41 +0100
Replied: "[e-mail] (Daniel LaLiberte) +python-list"
Received: by charon.cwi.nl with SMTP; Mon, 9 Dec 1991 20:17:26 +0100
Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA02055
  (5.65a/IDA-1.4.2 for [e-mail]); Mon, 9 Dec 91 13:12:15 -0600
Return-Path: <[e-mail]>
Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
    id AA05698; Mon, 9 Dec 91 13:11:20 CST
Date: Mon, 9 Dec 91 13:11:20 CST
From: [e-mail] (Daniel LaLiberte)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: passing/catching a variable number of args in python

    Daniel LaLiberte writes:
    >I dont think optional or rest args (in Lisp terminology) would work

    There is no such mechanism.

I was referring (without the explicit reference) to someone else's suggestion
to consider optional and rest args.  I rather like them too, and adding
them to current Python might be a problem.

    > [calling function of two arguments with 3 arguments...]

    There is no ambiguity.  This is a run-time error (detected in the
    called function), similar in nature to the error in assignments like
    "a, b = 1, 2, 3".

So in this situation, one is required to put the explicit parens in
(i.e. f((1, 2), 3)), but as a special case, you don't want to require
explicit parens in f(1, 2) when passed to a function declared f(p).
I can appreciate the motivation for this, but the inconsistency bothers
me more.

    >Alternatively, the function could be declared f((x, y)).

    Isn't Python's mechanism very similar (although probably implemented
    totally different), except that extra parentheses don't count?  After
    all, you can define a function as follows

        def f(a, (b, c, d), (e, (f, g))): ...

Oh, well I guess I forgot that Python can do this (can you tell I
am not an active user?).  In that case, I don't see any point in making
parens optional at the top level of an argument list, except for the
small convenience it affords sometimes.  Look at it this way: if the
user is grouping things in a tuple, the elements should have more
relationship to one another than just the fact that they will be passed
as a collective argument to a function.  And if doing away with this
"problem" leads to a better solution to the no argument/one argument
problem, I am all in favor of this code breaking change to Python syntax.

dan










Replied: Tue, 10 Dec 91 11:28:35 +0100
Replied: "[e-mail] (Daniel LaLiberte) +audio"
Received: by charon.cwi.nl with SMTP; Mon, 9 Dec 1991 20:23:45 +0100
Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA02533
  (5.65a/IDA-1.4.2 for [e-mail]); Mon, 9 Dec 91 13:20:26 -0600
Return-Path: <[e-mail]>
Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
    id AA05844; Mon, 9 Dec 91 13:19:29 CST
Date: Mon, 9 Dec 91 13:19:29 CST
From: [e-mail] (Daniel LaLiberte)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Other Python syntax changes

If you can do automatic static type checking without declarations, great!
But I suggested the general assertion mechanism as perhaps the more
valuable enhancement to python.  How about if a logical expression
appears as a statement, then the expression must evaluate to true.
If it fails, then an exception is raised.  This would avoid having
to introduce new syntax, but "=" would be a problem.  So add an
assert: expression statement.

dan










Received: by charon.cwi.nl with SMTP; Mon, 9 Dec 1991 22:45:06 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa25043;
          9 Dec 91 16:44 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA10771; Mon, 9 Dec 91 16:36:23 EST
Date: Mon, 9 Dec 91 16:36:23 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: passing/catching a variable number of args in python
Cc: [e-mail]

My notion was that:

a,b = 1,2,3

should unpack as:
 a = 1 ; b = ( 2, 3 )

and:

a,b,c = 1,2

as:
 a = 1; b = 2; c = None

I'm not sure that if it came to a vote, I would vote for my own
proposal - just thinking out loud at the moment.

I see the case as to whether or not an arg mismatch should raise an
error/exception as similar to the pro-con type checking argument:
 If python is intended for quickie programming, then it should
*REQUIRE* the minimum in type checking & other strictness. Given
any statement it should try to do something sensible ( within some
sensible bounds ). I believe you WILL want type checking or some sort
of consistency checking in larger programs/modules. In that case
there should be a "Python-lint" or some such program external to the
compiler/interpreter.

But I won't kill for that belief (yet :-)
( Also, as I said before, I don't know how the value 'None' is
 represented. )

Maybe Guido can give us some more details on consistency checking
in ABC. ( Or maybe I'll get off my duff and read the ABC doc's myself.)

- Steve










Replied: Tue, 10 Dec 91 01:15:21 +0100
Replied: [e-mail]
Received: by charon.cwi.nl with SMTP; Mon, 9 Dec 1991 23:18:31 +0100
Received: from PSUVM.PSU.EDU (MAILER@PSUVM) by HEARNVAX.nic.SURFnet.nl with
 PMDF#10216; Mon, 9 Dec 1991 23:19 MET
Received: by PSUVM (Mailer R2.08) id 5479; Mon, 09 Dec 91 17:16:30 EST
Date: Mon, 9 Dec 91 17:16 EST
From: [e-mail]
Subject: Python for MS-DOS?
To: [e-mail]
Message-Id: <[e-mail]>
X-Envelope-To: [e-mail]

I hope this is an appropriate forum for my question.  Where can
I get a copy of Python for my PC?  I have looked at a Canadian
site which was mentioned before but didn't find it there.

Thanks,

Carl Cotner
[e-mail]










Received: by charon.cwi.nl with SMTP; Mon, 9 Dec 1991 23:27:48 +0100
Received: from juno (juno.ericsson.se) by mailgate.ericsson.se (4.1/SMI-4.1-MAILGATE1.7)
    id AA16467; Mon, 9 Dec 91 23:27:42 +0100
Received: from juno21.ericsson.se by juno (4.1/SMI-4.1-LME1.6)
    id AA03273; Mon, 9 Dec 91 23:27:39 +0100
Received: by juno21.ericsson.se (4.1/client-1.3)
    id AA09438; Mon, 9 Dec 91 23:27:36 +0100
Date: Mon, 9 Dec 91 23:27:36 +0100
From: Mats Lidell TM/JUF 91753 <[e-mail]>
Message-Id: <[e-mail]>
To: Guido van Rossum <[e-mail]>
Cc: [e-mail]
Subject: Re: WHY PYTHON?
References: <[e-mail]>
    <[e-mail]>

Guido writes:

  Guido> If all OO languages were the more or less equivalent except
  Guido> for minor syntactic issues, this would be a reqsonable
  Guido> assumption.  However, as it is, this would make the OO model
  Guido> of the wrapper basically the same as that of the language it
  Guido> is wrapping.  I don't think you would want Python's OO
  Guido> mechanisms too tightly bound to those of C++.

Definitely not!! But I'm not sure how tight this bound has to be. If
you want to support everything you are probably in for trouble but
normally even C interfaces are very restricted in just allowing
passing of basic types between the sides (Sorry for not checking this
with Python :-).

  Guido> But the true reason why Python isn't based on C++ is of
  Guido> course availability.

Agreed!

  Guido> There's no reason why some extension modules of Python
  Guido> couldn't be written using C++, but of course this isn't the
  Guido> same as what you proposed.

Hmm... Well that's interesting (and maybe obvious). I guess I'd better
check how this works with Python before boring you to death on this
subject since this mailing list really is about Python :-)

%% Mats
"It is easier to fight for principles than to live up to them."
-- Alfred Adler










Received: by charon.cwi.nl with SMTP; Tue, 10 Dec 1991 01:15:21 +0100
Received: by voorn.cwi.nl with SMTP; Tue, 10 Dec 1991 00:15:20 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Python for MS-DOS?
In-Reply-To: Your message of "Mon, 09 Dec 91 17:16:00 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 10 Dec 91 01:15:19 +0100
Sender: [e-mail]

Carl Cotner writes:
>I hope this is an appropriate forum for my question.  Where can
>I get a copy of Python for my PC?  I have looked at a Canadian
>site which was mentioned before but didn't find it there.

I don't have a PC with a C compiler, so I can't help you personally.
However...

Long ago Mark Anacker posted patches for MS-DOS to alt.sources that
worked with version 0.9.1.

I have lost contact with Mark, but have incorporated his patches in
0.9.2, except for systematic changes to include file names to make
them short enough (I don't know if these were really necessary
anyway).  Of course, new changes, especially to the POSIX module,
could cause new trouble, but I believe that porting Python to MS-DOS
should be fairly simple, given a good C compiler (Turbo C or Microsoft
C) and somebody who's done this kind of work before.

Perhaps some appropriately equipped volunteer could try to do a port?
I'd be happy to assist via e-mail or telephone calls, and I will take
care of making the final binary avaiable by anon. ftp to the world.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I'm sorry, is this a five-minute argument, or the full half-hour?"










To: [e-mail] (Daniel LaLiberte)
Subject: Re: Other Python syntax changes
In-reply-to: Your message of "Mon, 09 Dec 91 13:19:29 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 10 Dec 91 11:28:39 +0100
Sender: guido

Assertions can easily be done without changes to the language, e.g. by
writing a function like this:

    def assert(test):
        if not test: raise <some exception>

I suppose this can be made into a standard module, complete with its
own exception, if there's enough demand (on the other hand, it's
trivial enough that interested parties can write it themselves).

--Guido










To: [e-mail] (Daniel LaLiberte)
Subject: Re: passing/catching a variable number of args in python
In-reply-to: Your message of "Mon, 09 Dec 91 13:11:20 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 10 Dec 91 11:38:44 +0100
Sender: guido

Sorry Dan, I am getting a little tired of this discussion of tuples
and arguments.  The current use of tuples in Python is quite
consistent (although totally different from superficially similar
mechanisms in other languages), and changing only argument passing is
not really possible without breaking lots of things in subtle ways.
This would just be too major a change to the language to be worth it.
After all *one* of the constraints to language changes is that I must
find the time to implement them...

--Guido










Replied: Wed, 11 Dec 91 23:46:50 +0100
Replied: "Steven D. Majewski" <[e-mail]>
Received: by charon.cwi.nl with SMTP; Wed, 11 Dec 1991 21:55:39 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa20019;
          11 Dec 91 15:55 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA10936; Tue, 10 Dec 91 12:12:44 EST
Date: Tue, 10 Dec 91 12:12:44 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Python for MS-DOS?

I will probably try porting python to MS-DOS ( unless someone else
does it first - I won't try to predict when I will be able to get
around to it. )
Any offhand guesses as to the memory requirements ?
Will it be usable in >640K or will I need a memory extender ?
I have ported a few things to DOS, but I'm not that adept in
portability requirements - I would think the goal for dos would
be to have an executable that could be shipped instead of the
sources. ( And some of the dos memory extenders will not allow
this without royalty agreements ! )

- Steve










Replied: Tue, 10 Dec 91 23:48:04 +0100
Replied: [e-mail] (Daniel LaLiberte)
Received: by charon.cwi.nl with SMTP; Tue, 10 Dec 1991 19:04:18 +0100
Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA14980
  (5.65a/IDA-1.4.2 for [e-mail]); Tue, 10 Dec 91 12:01:40 -0600
Return-Path: <[e-mail]>
Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
    id AA18008; Tue, 10 Dec 91 12:00:47 CST
Date: Tue, 10 Dec 91 12:00:47 CST
From: [e-mail] (Daniel LaLiberte)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Other Python syntax changes

    Assertions can easily be done without changes to the language, e.g. by
    writing a function like this:

        def assert(test):
            if not test: raise <some exception>

Although using a simple assert function goes a long way, there is more
that an full-blown assertion mechanism should do for the programmer.
e.g. often one wants to compare the previous value of an expression (when
a function was entered) with the current value.  Eiffel has a pretty
good assertion mechanism melded in with the class system, to constrain
the relationships between super classes and subclasses.  I dont think
you would want to go that far, but it has some good ideas.

The exception that is raised by a failed assertion should reflect the
caller of the assertion somehow, as well as the type of exception being
raised.  If the assert function can get at the caller by itself, then
all we need is a second parameter to indicate the exception type.

More daring folks (like myself) will want to compile out assertions
when they are satisfied that the code is "safe".  But assertions could
still be used as a control construct (when the exception is caught), so not
all assertions should be compiled out.

How could one do module or class invarients in Python?  These are
assertions that hold after any function in the module or class is
called.  One would want to declare the assertion only once and have
it called automatically after each function call (or whenever the
state of the module or class instance may be changed).  If there were a
hook on function calling or message sending, then a module or class
could just call the assertion in the hook function for that module or class.

An automatic type checker should be able to use assertions to assist
in type checking.

To do comparison with old values in current Python, one would have to
save the old value in a local variable explicitly, which is probably
more flexible and not too difficult.  Eiffel also has a notion of a
loop varient which is a non-negative integer expression that always
decreases in value after each loop.  This would be pretty messy to code
explicitly and probably wouldnt be used much in Python since many loops
are implicit or are already guarenteed to halt.

Well, enough for now.
dan










Replied: Tue, 10 Dec 91 23:36:31 +0100
Replied: [e-mail] (Daniel LaLiberte)
Received: by charon.cwi.nl with SMTP; Tue, 10 Dec 1991 19:11:54 +0100
Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA15251
  (5.65a/IDA-1.4.2 for [e-mail]); Tue, 10 Dec 91 12:09:17 -0600
Return-Path: <[e-mail]>
Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
    id AA18037; Tue, 10 Dec 91 12:08:23 CST
Date: Tue, 10 Dec 91 12:08:23 CST
From: [e-mail] (Daniel LaLiberte)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: passing/catching a variable number of args in python

    Sorry Dan, I am getting a little tired of this discussion of tuples
    and arguments.

Well, I've made my best pitch for the way I'd like to see things, so
there isnt much more to say.

    After all *one* of the constraints to language changes is that I must
    find the time to implement them...

Implementing this change to the "language" would only involve taking out
code to handle the special cases.  But if that breaks lots of code (a
significant part of the "language" no doubt), it would be better to fix
the code first to use the new convention as time permits and only then
change the language.

dan










To: [e-mail] (Daniel LaLiberte)
Subject: Re: passing/catching a variable number of args in python
In-reply-to: Your message of "Tue, 10 Dec 91 12:08:23 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 10 Dec 91 23:36:29 +0100
Sender: guido

>Implementing this change to the "language" would only involve taking out
>code to handle the special cases.

Which special cases?  I am not being a nuisance here; I really don't
think there are any special cases.  Maybe you can be specific about
what you think are special cases.  (Since we are now discussing this
in private, you can take as much space as you need, if it makes your
point.)

>But if that breaks lots of code (a
>significant part of the "language" no doubt), it would be better to fix
>the code first to use the new convention as time permits and only then
>change the language.

What exactly is the new convention you are proposing?  That "a,b=1,2,3"
assign 1 to a and (2,3) to b?  I would be vehemently opposed to this,
as well as to its equivalent in argument passing.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Oh Bevis!  And I thought you were so rugged!"










To: [e-mail] (Daniel LaLiberte)
Subject: Re: Other Python syntax changes
In-reply-to: Your message of "Tue, 10 Dec 91 12:00:47 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 10 Dec 91 23:48:02 +0100
Sender: guido

>The exception that is raised by a failed assertion should reflect the
>caller of the assertion somehow, as well as the type of exception being
>raised.  If the assert function can get at the caller by itself, then
>all we need is a second parameter to indicate the exception type.

I *think* there is a way of getting at the stack trace from within a
function.  There certainly is a way to do this from within an
exception handler -- the Python debugger uses this.

>More daring folks (like myself) will want to compile out assertions
>when they are satisfied that the code is "safe".  But assertions could
>still be used as a control construct (when the exception is caught), so not
>all assertions should be compiled out.

Well, there's "raise" for that, which is never compiled out.

>How could one do module or class invarients in Python?  These are
>assertions that hold after any function in the module or class is
>called.  One would want to declare the assertion only once and have
>it called automatically after each function call (or whenever the
>state of the module or class instance may be changed).  If there were a
>hook on function calling or message sending, then a module or class
>could just call the assertion in the hook function for that module or class.

Now there's an interesting idea.  It wouldn't be too hard to break
parts of the interpreter open and allow the user to specify "hooks"
that are called when various interesting things happen, such as
calling a function, returning from a function, or perhaps executing
any instruction.  This could easily be specified on a per-function
basis, and would make for a very general tracing and debugging
facility...

I'd like to define it in such a way that it can't be used (or at least
doesn't encourage use) to change the "local" semantics of Python, but
side effects of the kind that a trace or log facility must have would
be fine.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"All right, it's a fair cop, but society is to blame."










Received: by charon.cwi.nl with SMTP; Wed, 11 Dec 1991 18:38:57 +0100
Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA16463
  (5.65a/IDA-1.4.2 for [e-mail]); Wed, 11 Dec 91 11:34:55 -0600
Return-Path: <[e-mail]>
Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
    id AA26453; Wed, 11 Dec 91 11:34:00 CST
Date: Wed, 11 Dec 91 11:34:00 CST
From: [e-mail] (Daniel LaLiberte)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: passing/catching a variable number of args in python

    >Implementing this change to the "language" would only involve taking
    >out code to handle the special cases.

    Which special cases?

I guess I was only thinking of one special case: in argument passing, if
there is one formal argument in a function declaration, then no matter how
many actual arguments are given, they are all packaged up in a tuple for
the one formal argument. So for

def f(x) ...

The call f(1, 2) puts the tuple (1, 2) in x.
This case has some similarity with the following, but they are quite
different nevertheless.

def f(x, y) ...

f((1, 2), 3)   -- x is given (1, 2).

----
Consider the following.

def f((x, y), z)

f((1, 2), 3, 4)  -- an error
f((1, 2), (3, 4))  -- so parens around 3, 4 is required
f((1, (2.1, 2.2)), (3, 4))  -- y gets (2.1, 2.2)  I have no problem here

def f((x), y)

f((1), 2)     -- x gets 1
f((1, 2), 3)  -- this I don't like.  should x get tuple (1, 2)?  I say no.
        -- an error would be more consistent.  what does python do?

    What exactly is the new convention you are proposing?  That "a,b=1,2,3"
    assign 1 to a and (2,3) to b?  I would be vehemently opposed to this,
    as well as to its equivalent in argument passing.

I would be opposed too.  In fact, I am going the other direction.

a = 1, 2, 3 has the same problem described above
as def f(a) given f(1, 2, 3).

I propose that instead of a = 1, 2, 3, one must say a = (1, 2, 3)
and instead of def f(a) given f(1, 2, 3) one must say f((1, 2, 3)).
Or if one wishes to break out the components of a tuple in a function,
one could def f((x, y, z)) and be given the same f((1, 2, 3)) or just
f(xyz) where xyz = (1, 2, 3).  But def f(x, y, z) can only be given
three separate arguments, e.g. f(1, 2, 3).

The rule is that for a left hand side (or formal argument list),
there must be a one-to-one correspondence between names and values on
the right hand side (or actual argument list).  This same rule is applied
consistently recursively.

To implement this, you could still build an implicit tuple out of
actual arguments, but build the corresponding implicit tuple out of formal
arguments and do the matching on corresponding elements of the tuples,
recursively.  The same for assignment.

Now that I have presented it more clearly, I am more convinced myself that
this is the right way to go.  I am not sure how this proposal fits in with
zero argument functions and methods and (1,) style tuples, but I would
bet that doing away with this special case makes other things simpler.

Had you considered matching corresponding elements of lists too?
So def f([a, b]) could be given f([1, 2]).

Some way of doing explicit optional and rest arguments could be added
given this new consistent convention.  So def f(a, b?, c*) might mean b is
optional and c gets all following arguments in a tuple.  f(1, 2, 3, 4)
puts (3, 4) in c.  But f(1, 2, 3) puts (3,) in c.  f(1) puts Novalue in b
and perhaps () in c.

dan










To: "Steven D. Majewski" <[e-mail]>
Subject: Re: Python for MS-DOS?
In-reply-to: Your message of "Tue, 10 Dec 91 12:12:44 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Wed, 11 Dec 91 23:46:48 +0100
Sender: guido

>I will probably try porting python to MS-DOS ( unless someone else
>does it first - I won't try to predict when I will be able to get
>around to it. )

Thanks, I haven't found any other volunteers except a guy in South
Africa who seems to have no porting experience at all.

>Any offhand guesses as to the memory requirements ?
>Will it be usable in >640K or will I need a memory extender ?

On the Mac the interpreter is about 200 kBytes and runs in 1 Meg,
although it runs out of memory parsing long modules such as testall.py
(which really should be split anyway).  This includes the STDWIN
module which doesn't apply on the PC.  I expect it will be at least
somewhat functional on the PC in 640 k.  I don't know anything about
memory expanders; they will have to be integrated with malloc (so the
program can allocate expanded memory using malloc) or you'd be in deep
trouble using one.

>I have ported a few things to DOS, but I'm not that adept in
>portability requirements - I would think the goal for dos would
>be to have an executable that could be shipped instead of the
>sources.

That's my idea as well.

>( And some of the dos memory extenders will not allow
>this without royalty agreements ! )

That would be out of the question :-(

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"It's funny, isn't it?  How your best friend can just blow up like that?
I mean, you wouldn't think it was medically possible, would you?"










To: [e-mail] (Daniel LaLiberte)
Subject: Re: passing/catching a variable number of args in python
In-reply-to: Your message of "Wed, 11 Dec 91 11:34:00 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 12 Dec 91 14:08:32 +0100
Sender: guido

You did a fine job: you've convinced me that there is a way to change
Python's argument passing without breaking the whole language, and
allowing several problems with arguments to be fixed.  I even think
that this can be done in an almost backward-compatible way (which is
important to myself, since I've got over 10,000 lines of Python code
lying around...).

Still no guarantees that I'll do it, but it sounds attractive since it
would solve two current problems: the exceptional position of
functions without arguments and the weird argument lists required for
methods.

I don't think it is necessary to change assignments at all.  The most
important new rule would be:

1.    Formal and actual parameter lists are *always* seen as
    tuples: a single parameter is seen as a singleton tuple, an
    empty parameter list is seen as an empty tuple.

(It is important to realize that in Python the caller has no idea of
the callee's formal parameter list, so there must be an agreed upon
representation of actual parameter lists.)

Two extra rules provide coercion between tuples and single parameters;
these are only invoked (in the callee, when receiving the argument
list) if the number of actual and formal parameters don't match:

2.    If there is exactly one actual parameter and 0 or 2 or more
    formal parameters, the actual parameter must be a tuple with
    as many items, and its items are distributed over the formal
    parameters.

3.    If there is exactly one formal parameter and 0 or 2 or more
    actual parameters, the formal paramater receives the tuple of
    actual parameters.

Rule 2 makes it possible to do:

    def f(a, b, c): ...

    x = 1, 2, 3
    f(x)        # equivalent to f(1, 2, 3)

which is important if you have a function and an argument list that
you want to save somewhere (perhaps pass it to another module) so it
can be called later.  The old system had an anomaly that such a module
couldn't both handle function calls with and without arguments; the
new system lets you pass "f, ()" in this case.

Rule 3 handles the reverse case:

    def f(x): ...

    f(1, 2, 3)    # equivalent to f((1, 2, 3))

which makes it possible to let the function detect the number of
arguments.  This still requires the callee to handle a single actual
parameter special (since then the formal parameter won't be a tuple).
Also this mechanism makes it impossible to pass a variadic function
one argument which is a tuple -- I'm not sure if this is a problem,
but if it is, we are now able to define special syntax in the formal
parameter list to handle variable length argument lists special (e.g.,
&rest).

One problem left to solve is the mapping from method calls to function
calls.  We can now get rid of the silly convention that a method with
more than one argument must enclose all arguments except "self" in
extra parentheses:

    # old style
    class C():
        def method(self, (x, y, z)): ...

can now become

    # new style
    class C:
        def method(self, x, y, z): ...

I haven't thought about a backward compatibility hack here -- perhaps
I'll solve that with a script...

Now I have to get back to your mail.

>def f((x), y)
>
>f((1), 2)     -- x gets 1
>f((1, 2), 3)  -- this I don't like.  should x get tuple (1, 2)?  I say no.
>        -- an error would be more consistent.  what does python do?

Currently "def f((x), y)" is indistinguishable from "def f(x, y)",
just as "(1)+1" is indistinguishable from "1+1".  I'd like to keep
this rule in general.  My proposal above only makes the outermost
parentheses of function calls and declarations special.

>I propose that instead of a = 1, 2, 3, one must say a = (1, 2, 3)

I don't see why this requirement would improve the language.

>and instead of def f(a) given f(1, 2, 3) one must say f((1, 2, 3)).

Not with my proposal, because of rule 3.

>Had you considered matching corresponding elements of lists too?
>So def f([a, b]) could be given f([1, 2]).

Not too useful, since lists are mostly used when they may vary in
length.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"That was never five minutes just now!"
"I'm afraid it was."










Received: by charon.cwi.nl with SMTP; Thu, 12 Dec 1991 18:05:46 +0100
Received: from yoyodyne.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA00115
  (5.65a/IDA-1.4.2 for [e-mail]); Thu, 12 Dec 91 11:04:03 -0600
Return-Path: <[e-mail]>
Received: by yoyodyne.ncsa.uiuc.edu (4.0/NCSA-4.1)
    id AA16424; Thu, 12 Dec 91 11:02:34 CST
Date: Thu, 12 Dec 91 11:02:34 CST
From: [e-mail] (Daniel LaLiberte)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: passing/catching a variable number of args in python

    You did a fine job: you've convinced me that there is a way to change
    Python's argument passing without breaking the whole language, and
    allowing several problems with arguments to be fixed.

Well, I'm glad we persisted then.  But from your counter proposal, my
main contribution seems to be rule 1.  I would also, over time, do away
with rules 2 and 3, which seem to exist mostly for backward compatibility.
I would try to provide their unique features in some other way;
in Lisp, rule 2 would be replaced by using apply and rule 3 by &rest args.

    I don't think it is necessary to change assignments at all.

No, it isn't necessary, just more consistent.  But given rules 2 and 3,
doing "a = 1, 2, 3" and "a, b, c = (1, 2, 3)" is consistent.


    Now I have to get back to your mail.

    >def f((x), y)
    >
    >f((1), 2)     -- x gets 1
    >f((1, 2), 3)  -- this I don't like.  should x get tuple (1, 2)?  I say no.
    >        -- an error would be more consistent.  what does python do?

    Currently "def f((x), y)" is indistinguishable from "def f(x, y)",
    just as "(1)+1" is indistinguishable from "1+1".  I'd like to keep
    this rule in general.  My proposal above only makes the outermost
    parentheses of function calls and declarations special.

OK, how about def f((x, ), y) then?

    >Had you considered matching corresponding elements of lists too?
    >So def f([a, b]) could be given f([1, 2]).

    Not too useful, since lists are mostly used when they may vary in
    length.

Well, granted my suggestion above is not too useful by itself.
But if lists vary in length, then it would be more useful to have
a way of matching all remaining elements of a list.

Feel free to use any of my mail in a summary to the python list if
you wish.

dan










Received: by charon.cwi.nl with SMTP; Thu, 19 Dec 1991 05:26:02 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa24042;
          18 Dec 91 23:25 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA09202; Wed, 18 Dec 91 23:16:58 EST
Date: Wed, 18 Dec 91 23:16:58 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: python moved/re-moved from wuarchive.wuslt.edu:/pub


>From Tim Peters / [e-mail]
I hear that the python distribution is no longer in wuarchive.wuslt.edu:/pub

I currenly have a copy in uvaarpa.virginia.edu:/public_access/Python.tar.Z

This is not the original distribution, but a superset, including
Gnu-readline-library, STDWIN library & programs & python.beta.0.92
including binaries for SPARC/SunOS4.1.1.

It is *rather* large.

I will probably put the original there also, if needed.
Any other USA ftp sites ?

- Steve Majewski










Received: by charon.cwi.nl with SMTP; Mon, 23 Dec 1991 19:19:36 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa13749;
          23 Dec 91 13:19 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA04380; Mon, 23 Dec 91 13:10:52 EST
Date: Mon, 23 Dec 91 13:10:52 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: miscellaneous

--------
>>>( 1 > 0.0 )
1

- OK on my machine.
  ( Tim: you must have re-built the binaries for your machine, or
    else it is stranger still... )
--------

Re: Fixed in 0.9.4
 Is 0.9.4 ready and available yet ?
 ( I will try to keep a current distribution on uvaarpa.virginia.edu
   for U.S. - What is there now is my combined ( Readline & STDWIN )
   version of 0.9.2 with the one tiny #include patch for RS6000
   and SPARC/SunOS 4.1.1 binaries. That was stuck there so that so
   that some other people at UVA could grab it and install it on the
   SparcStations here quickly, but in the future, I'll try to keep
   a "vanilla" copy of the latest release. )
 Can you ( Guido ) post a "changes" file to the list when available ?

---------

 Re: '==' replacing '=' for comparison

 Yes. That was on my list of minor complaints. I don't think comparison
 and assignment should have the same symbol. If changing also makes
 the grammar/parser easier, then go ahead!  '==' for equality is
 probably better that ':=' for assignment, as assignment is probably
 the more frequent operation.

---------

In General ( Re: scope & binding thread )

 I agree that the rules in python are not too difficult to understand.
 They are just different from what one expects, but that is certainly
 no reason to change. ( In fact many of the things I like most about
 python are outgrowths of it's object-oriented ( I mean in the object
 .vs. value sense ), name spaces, and assignment-is-name-binding. )

 I'm quite willing to learn the python way of doing things, as long as
 that is clearly spelled out. ( In fact, I've been holding off on
 the "what python needs is ..." comments until I feel that I *DO*
 grasp that notion more firmly. )

 What is needed is to merge some of the points discussed here into the
 users guide - a prominent part of the intro should explain what is
 different about python - with a more in depth treatment in the Lang.
 Reference Manual.

 ( I'm sure you've got plenty of work to do already, Guido. I hope
   that this discussion has been some help in clarifying the questions,
   ( I never understand what *I* mean until I hear myself explain it :-)
   rather than merely drain of your time & resources. )

-----------

 ( A longer post on names & classes follows... )

 - Steve Majewski











Received: by charon.cwi.nl with SMTP; Mon, 23 Dec 1991 20:27:08 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa16514;
          23 Dec 91 14:27 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA04490; Mon, 23 Dec 91 14:18:27 EST
Date: Mon, 23 Dec 91 14:18:27 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Nameless objects have name spaces ( huzzah! hurray! :-)


The further discussion of names & binding in python raises some
dormant questions in my mind.

Guido's comment that in python: "an expression does not compute a
value but yields an object" is, like "assignment is not the modification
of a storage cell, but the binding of a name to an object", a seminal
point. These two sentences should be somewhere prominent in the user
guide - in *BOLD* or underlined!

It has some implications I haven't fully thought out yet.
( I *was* prepared to argue that, to exploit interactive terseness,
  all python expressions should yield values ( like in C or ICON )
  and that side effect expressions ( like C: if ( ( n = read() ) == max ) ... )
  should be allowed, as well as op-assignment ( +=, etc. ).
  Mainly because python loops often seem to require some "forethought" :
  perhaps not a bad thing for a programmer to be forced into :-), but in
  interactive use, it can be an annoyance.
  I am rethinking this position. )

It *DID* inspire me to discover that un-named objects also have a
name space.

(*example*):

>>> class Thing():
...  pass
...
>>> T = ( Thing(), Thing(), Thing() )
>>> T
(<instance object at 7af78>, <instance object at 83470>, <instance object at 83)
>>>
>>> type( T )
<type 'tuple'>
>>>
>>> T[0]
<instance object at 7af78>
>>>
>>> type( T[0] )
<type 'instance'>
>>>
>>> for x in T :
...   x.L = []
...   x.i = 0
...
>>> T[0]
<instance object at 7af78>
>>> T[0].L
[]
>>>
>>> T[0].i
0
>>>

The application of this is that I would like to transform my tuple of
tuples into a tuple of objects without cluttering up the namespace
with what should be anonymous objects.
E.g. I have a list of tuples:
 [ ( IdNumber, 'Na4-P2-O7', ( 'Na', 4, peak-count-for-Na ),
               ( 'P',  2, peak-count-for-P ) )  ... ]
( Perhaps this structure can be cleaned up a bit in it's logical grouping,
but the point is: )
References like: x[0][2][2] get to be a bit opaque. But each item is
a pair in  a larger list, and I don't want/need them each to be named.



This example, however, leads me back to one of my other problems/complaints
with python classes:
 I does not seem possible ( to me: I may not understand this correctly )
 to initialize an object at it's creation. i.e. what I want to be able
 to do is something like:

class Thing( y ):
  Thing.x = y
  Thing.i = 0

or

class Thing():
  def init( me ):
    me.L = []
    me.i = 0
    return me
  Thing().init()

But I have been unable to find an acceptable syntax variation of the
above that is accepted.

BUT:
>>> Thing().L = []

Does work.
Though:

>>> a = ( Thing().L = [] )
Unhandled exception: undefined name: L
Stack backtrace (innermost last):
  File "<stdin>", line 1
>>>

Obviously does not, since the parends make it look like comparison
is intended. ( Will this work when "equals" becomes '==' ? )


Actually, while writing this note, I have been swapping between
emacs & python to try examples, and I finally figured out how to
do what I want ( But I will go ahead and send this, instead of
just saying "Nevermind", for discussion sake. ):

>>> class Thing():
...   def init(me):
...     me.L = []
...     me.i = 0
...     return me
...
>>> T = ( Thing().init(), Thing().init() )
>>> T
(<instance object at 7add0>, <instance object at 836f0>)
>>> T[0]
<instance object at 7add0>
>>> T[0].i
0
>>> T[0].L
[]
>>>
>>> a = Thing().init()
>>> a
<instance object at 84908>
>>> a.i
0
>>> a.L
[]
>>>

I *still* think it would be nice if there was a way to MAKE classes
become initialized when created  as part of their definition,
rather that by explicitly calling an init() function. ( Is there
a way that I'm missing ? ) But I can probably live with the above
method.

- Steve Majewski










Received: by charon.cwi.nl with SMTP; Mon, 23 Dec 1991 23:01:26 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa23518;
          23 Dec 91 17:01 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA04621; Mon, 23 Dec 91 16:52:42 EST
Date: Mon, 23 Dec 91 16:52:42 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: disappearance of python

Not only is python.9.2 no longer in wuarchive.wustl.edu:/pub
but I do not see it on uunet.uu.net:/tmp or
gatekeeper.dec.com:/pub/misc/python

And ftp.nluug.nl & mcsun.eu.net only seem to have v 9.1.

Is there some insideous plot by Perl users to stamp out python ?
( I *have* spotted a live elvis.tar.Z, so anything is possible... :-)

Merry Christmas to all,
 - Steve










Received: by charon.cwi.nl with SMTP; Mon, 23 Dec 1991 23:26:46 +0100
Received: by paring.cwi.nl ; Mon, 23 Dec 91 23:26:44 +0100
Date: Mon, 23 Dec 91 23:26:44 +0100
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  disappearance of python

 > Not only is python.9.2 no longer in wuarchive.wustl.edu:/pub
 > but I do not see it on uunet.uu.net:/tmp or
 > gatekeeper.dec.com:/pub/misc/python
 >
 > And ftp.nluug.nl & mcsun.eu.net only seem to have v 9.1.
 >
 > Is there some insideous plot by Perl users to stamp out python ?
 > ( I *have* spotted a live elvis.tar.Z, so anything is possible... :-)
Perhaps.  For the time being at least it is available from:
    ftp.cwi.nl:/pub/python0.9.2beta.tar.Z
I do not know whether that is exactly the same version (Guido will know
that).
 >
 > Merry Christmas to all,
Same, dik
--
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
[e-mail]










To: [e-mail]
Subject: Re: Steve Majewski's mail
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 24 Dec 91 12:02:43 +0100
Sender: guido

Steve Majewski replied on the list to a message not sent to the list;
I hope y'all list readers can figure out the issues from what he quoted.
I'll only reply to points that are still unclear.

> Is 0.9.4 ready and available yet ?

Good question.  I could either release what I currently have as
"0.9.4" or stick to it a little longer.  My main reason for not
releasing it is that I still (sigh) haven't found the time to update
all the documentation.  However a new release since 0.9.2beta is long
overdue so maybe I'll release it *without* up-to-date documentation.
I will post an announcement with a summary of changes on the list when
it's ready.  People who have a strong opinion about releasing or not
releasing should send mail to me privately so I can just tally the
votes.

> Re: '==' replacing '=' for comparison
>
> Yes. That was on my list of minor complaints. I don't think comparison
> and assignment should have the same symbol. If changing also makes
> the grammar/parser easier, then go ahead!  '==' for equality is
> probably better that ':=' for assignment, as assignment is probably
> the more frequent operation.

I agree, reluctantly (because of all the lines of library and example
code I will have to change), that this change should be made; but it
won't be in 0.9.4 if I release that soon.  Note that this still won't
give you assignments in expressions as side effects; I am against such
a feature even though it occasionally saves a line of code -- one of
Python's strong points is that it is usually very easy (and pretty!)
to read, and I feel that assignments in expressions would have a
strong negative effect on readability (and prettiness!).

> What is needed is to merge some of the points discussed here into the
> users guide - a prominent part of the intro should explain what is
> different about python - with a more in depth treatment in the Lang.
> Reference Manual.

The current "tutorial" tries to keep object-oriented features out of
sight for as long as possible, in order to explain other pertinent
features like the syntax and the high-level data types and operations
(list slicing etc.).  Do people think this characteristic of the
tutorial should be changed in favor of a more agressive explanation of
OO features?  (I have heard people say that the tutorial is a
"read-once" document -- perhaps a real user's guide is needed, at a
level between the tutorial and the reference?)

(Here starts Steve's next mail):

>Actually, while writing this note, I have been swapping between
>emacs & python to try examples, and I finally figured out how to
>do what I want ( But I will go ahead and send this, instead of
>just saying "Nevermind", for discussion sake. ):

You can do that in private e-mail, but perhaps you should edit your
messages to the list a little more carefully.  BTW, have you read the
document misc/CLASSES which comes with the Python distribution?  That
should have made several points you are slowly discovering here clear
from the start (if not, please point out where it fails to be clear).

>I *still* think it would be nice if there was a way to MAKE classes
>become initialized when created  as part of their definition,
>rather that by explicitly calling an init() function. ( Is there
>a way that I'm missing ? ) But I can probably live with the above
>method.

Class initialization in Python does not have the greatest syntax.
This is one point where I was experimenting with language design.

Perhaps I could adopt the Modula-3 way (after all I stole enough from
M3 already): a built-in function new() with as its first argument a
class name and as further arguments the arguments to class's init
code.  We also need a way for the user to specify the init code; a
function with a standard name ("init" comes to mind :-) seems fine to
me.

Note that the statements executed in the class definition cannot be
used for this purpose -- these statements are executed *once*, when
the class is defined, and their main purpose is to execute the method
definitions (since a 'def' statement must have been executed in Python
before it takes effect).

Finally, on the issue of the disappearing Pythons:

>    ftp.cwi.nl:/pub/python0.9.2beta.tar.Z

is indeed tha latest official release and identical to those that once
were on wuarchive.  I think I cannot blame the archive keepers for
deleting old files every once in a while.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I could be arguing in my spare time."










Received: by charon.cwi.nl with SMTP; Tue, 24 Dec 1991 12:02:44 +0100
Received: by voorn.cwi.nl with SMTP; Tue, 24 Dec 1991 11:02:43 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Steve Majewski's mail
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 24 Dec 91 12:02:43 +0100
Sender: [e-mail]

Steve Majewski replied on the list to a message not sent to the list;
I hope y'all list readers can figure out the issues from what he quoted.
I'll only reply to points that are still unclear.

> Is 0.9.4 ready and available yet ?

Good question.  I could either release what I currently have as
"0.9.4" or stick to it a little longer.  My main reason for not
releasing it is that I still (sigh) haven't found the time to update
all the documentation.  However a new release since 0.9.2beta is long
overdue so maybe I'll release it *without* up-to-date documentation.
I will post an announcement with a summary of changes on the list when
it's ready.  People who have a strong opinion about releasing or not
releasing should send mail to me privately so I can just tally the
votes.

> Re: '==' replacing '=' for comparison
>
> Yes. That was on my list of minor complaints. I don't think comparison
> and assignment should have the same symbol. If changing also makes
> the grammar/parser easier, then go ahead!  '==' for equality is
> probably better that ':=' for assignment, as assignment is probably
> the more frequent operation.

I agree, reluctantly (because of all the lines of library and example
code I will have to change), that this change should be made; but it
won't be in 0.9.4 if I release that soon.  Note that this still won't
give you assignments in expressions as side effects; I am against such
a feature even though it occasionally saves a line of code -- one of
Python's strong points is that it is usually very easy (and pretty!)
to read, and I feel that assignments in expressions would have a
strong negative effect on readability (and prettiness!).

> What is needed is to merge some of the points discussed here into the
> users guide - a prominent part of the intro should explain what is
> different about python - with a more in depth treatment in the Lang.
> Reference Manual.

The current "tutorial" tries to keep object-oriented features out of
sight for as long as possible, in order to explain other pertinent
features like the syntax and the high-level data types and operations
(list slicing etc.).  Do people think this characteristic of the
tutorial should be changed in favor of a more agressive explanation of
OO features?  (I have heard people say that the tutorial is a
"read-once" document -- perhaps a real user's guide is needed, at a
level between the tutorial and the reference?)

(Here starts Steve's next mail):

>Actually, while writing this note, I have been swapping between
>emacs & python to try examples, and I finally figured out how to
>do what I want ( But I will go ahead and send this, instead of
>just saying "Nevermind", for discussion sake. ):

You can do that in private e-mail, but perhaps you should edit your
messages to the list a little more carefully.  BTW, have you read the
document misc/CLASSES which comes with the Python distribution?  That
should have made several points you are slowly discovering here clear
from the start (if not, please point out where it fails to be clear).

>I *still* think it would be nice if there was a way to MAKE classes
>become initialized when created  as part of their definition,
>rather that by explicitly calling an init() function. ( Is there
>a way that I'm missing ? ) But I can probably live with the above
>method.

Class initialization in Python does not have the greatest syntax.
This is one point where I was experimenting with language design.

Perhaps I could adopt the Modula-3 way (after all I stole enough from
M3 already): a built-in function new() with as its first argument a
class name and as further arguments the arguments to class's init
code.  We also need a way for the user to specify the init code; a
function with a standard name ("init" comes to mind :-) seems fine to
me.

Note that the statements executed in the class definition cannot be
used for this purpose -- these statements are executed *once*, when
the class is defined, and their main purpose is to execute the method
definitions (since a 'def' statement must have been executed in Python
before it takes effect).

Finally, on the issue of the disappearing Pythons:

>    ftp.cwi.nl:/pub/python0.9.2beta.tar.Z

is indeed tha latest official release and identical to those that once
were on wuarchive.  I think I cannot blame the archive keepers for
deleting old files every once in a while.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I could be arguing in my spare time."










Received: by charon.cwi.nl with SMTP; Tue, 24 Dec 1991 13:20:19 +0100
Received: by voorn.cwi.nl with SMTP; Tue, 24 Dec 1991 12:20:18 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Python 0.9.4alpha under the Christmas tree!
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 24 Dec 91 13:20:17 +0100
Sender: [e-mail]

After all I think it's better to release 0.9.4 now to see what people
think of it anyway, rather than waiting forever until I find the time
to perfect the documentation (it certainly isn't going to happen over
Christmas).

I've uploaded it to the following three places:

    host            directory

    uunet.uu.net        /tmp
    wuarchive.wustl.edu    /pub
    ftp.cwi.nl        /pub

You should fetch the file python0.9.4alpha.tar.Z.  If you haven't got
STDWIN yet, you can fetch that too, from the same locations; the file
is stdwin0.9.6.tar.Z.  I don't know what's an appropriate place to get
bash/readline from, sorry.

I don't know how long the uunet and wuarchive versions will stay
around; I have some control over ftp.cwi.nl so I think those versions
will stay put, but people in North America should first try either US
site to avoid excessive transatlantic traffic (and Europeans should
try ftp.cwi.nl first!).

Don't ask me to mail it to you; find a friend with Internet ftp access
instead.

Below are the PREFACE and NEWS files from the distribution (directory
misc):

---------------------------------- NEWS --------------------------------
This is the announcement of Python 0.9.4 alpha.  I call it an alpha
release because it is not widely distributed, only to readers of the
Python mailing list, and because the documentation does not yet
describe the new features yet.  However, installation should be
smooth, and I don't expect there are obvious bugs left.

In particular, these changes are not yet documented:

- New class syntax, without extraneous parentheses.
- New 'global' statement to assign global variables from within a function.
- New, more refined exceptions.
- New argument passing semantics.

The release can be picked up by anonymous ftp from site ftp.cwi.nl,
directory pub, file python0.9.4beta.tar.Z.  I will also upload
versions to wuarchive.wustl.edu:/pub and to uunet.uu.net:/tmp.  Please
don't ask me to mail it to you; find a friend with Internet ftp access
instead.

The rest of this file contains explanation for the changes listed above.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Oh Bevis!  And I thought you were so rugged!"


New class syntax
----------------

You can now declare a base class as follows:

    class B:            # Was: class B():
        def some_method(self): ...
        ...

and a derived class thusly:

    class D(B):            # Was: class D() = B():
        def another_method(self, arg): ...

Multiple inheritance looks like this:

    class M(B, D):            # Was: class M() = B(), D():
        def this_or_that_method(self, arg): ...

The old syntax is still accepted by Python 0.9.4, but will disappear
in Python 1.0 (to be posted to comp.sources).


New 'global' statement
----------------------

Every now and then you have a global variable in a module that you
want to change from within a function in that module -- say, a count
of calls to a function, or an option flag, etc.  Until now this was
not directly possible.  While several kludges are known that
circumvent the problem, and often the need for a global variable can
be avoided by rewriting the module as a class, this does not always
lead to clearer code.

The 'global' statement solves this dilemma.  Its occurrence in a
function body means that, for the duration of that function, the
names listed there refer to global variables.  For instance:

    total = 0.0
    count = 0

    def add_to_total(amount):
        global total, count
        total = total + amount
        count = count + 1

'global' must be repeated in each function where it is needed.  The
names listed in a 'global' statement must not be used in the function
before the statement is reached.

Remember that you don't need to use 'global' if you only want to *use*
a global variable in a function; nor do you need ot for assignments to
parts of global variables (e.g., list or dictionary items or
attributes of class instances).  This has not changed; in fact
assignment to part of a global variable was the standard workaround.


New exceptions
--------------

Several new exceptions have been defined, to distinguish more clearly
between different types of errors.

name            meaning                    was

AttributeError        reference to non-existing attribute    NameError
IOError            unexpected I/O error            RuntimeError
ImportError        import of non-existing module or name    NameError
IndexError        invalid string, tuple or list index    RuntimeError
KeyError        key not in dictionary            RuntimeError
OverflowError        numeric overflow            RuntimeError
SyntaxError        invalid syntax                RuntimeError
ValueError        invalid argument value            RuntimeError
ZeroDivisionError    division by zero            RuntimeError

The string value of each exception is now its name -- this makes it
easier to experimentally find out which operations raise which
exceptions; e.g.:

    >>> KeyboardInterrupt
    'KeyboardInterrupt'
    >>>


New argument passing semantics
------------------------------

Off-line discussions with Steve Majewski and Daniel LaLiberte have
convinced me that Python's parameter mechanism could be changed in a
way that made both of them happy (I hope), kept me happy, fixed a
number of outstanding problems, and, given some backward compatibility
provisions, would only break a very small amount of existing code --
probably all mine anyway.  In fact I suspect that most Python users
will hardly notice the difference.  And yet it has cost me at least
one sleepless night to decide to make the change...

Philosophically, the change is quite radical (to me, anyway): a
function is no longer called with either zero or one argument, which
is a tuple if there appear to be more arguments.  Every function now
has an argument list containing 0, 1 or more arguments.  This list is
always implemented as a tuple, and it is a (run-time) error if a
function is called with a different number of arguments than expected.

What's the difference? you may ask.  The answer is, very little unless
you want to write variadic functions -- functions that may be called
with a variable number of arguments.  Formerly, you could write a
function that accepted one or more arguments with little trouble, but
writing a function that could be called with either 0 or 1 argument
(or more) was next to impossible.  This is now a piece of cake: you
can simply declare an argument that receives the entire argument
tuple, and check its length -- it will be of size 0 if there are no
arguments.

Another anomaly of the old system was the way multi-argument methods
(in classes) had to be declared, e.g.:

    class Point():
        def init(self, (x, y, color)): ...
        def setcolor(self, color): ...
        dev moveto(self, (x, y)): ...
        def draw(self): ...

Using the new scheme there is no need to enclose the method arguments
in an extra set of parentheses, so the above class could become:

    class Point:
        def init(self, x, y, color): ...
        def setcolor(self, color): ...
        dev moveto(self, x, y): ...
        def draw(self): ...

That is, the equivalence rule between methods and functions has
changed so that now p.moveto(x,y) is equivalent to Point.moveto(p,x,y)
while formerly it was equivalent to Point.moveto(p,(x,y)).

A special backward compatibility rule makes that the old version also
still works: whenever a function with exactly two arguments (at the top
level) is called with more than two arguments, the second and further
arguments are packed into a tuple and passed as the second argument.
This rule is invoked independently of whether the function is actually a
method, so there is a slight chance that some erroneous calls of
functions expecting two arguments with more than that number of
arguments go undetected at first -- when the function tries to use the
second argument it may find it is a tuple instead of what was expected.
Note that this rule will be removed from future versions of the
language; it is a backward compatibility provision *only*.

Two other rules and a new built-in function handle conversion between
tuples and argument lists:

Rule (a): when a function with more than one argument is called with a
single argument that is a tuple of the right size, the tuple's items
are used as arguments.

Rule (b): when a function with exactly one argument receives no
arguments or more than one, that one argument will receive a tuple
containing the arguments (the tuple will be empty if there were no
arguments).


While no new argument syntax was added in this phase, it would now be
quite sensible to add explicit syntax to Python for default argument
values (as in C++ or Modula-3), or a "rest" argument to receive the
remaining arguments of a variable-length argument list.

-------------------------------- PREFACE -------------------------------
This is Python release 0.9.4 alpha
==================================


What is Python?
---------------

Python is an interpreted prototyping language, incorporating modules,
exceptions, dynamic typing, very high level dynamic data types, and
classes.  Python combines remarkable power with very clear syntax.  It
has interfaces to many system calls and libraries, as well as to
various window systems, and is extensible in C.  It is also usable as
an extension language for applications that need a programmable
interface.  Finally, Python is portable: it runs on many brands of
UNIX, on the Mac, and maybe on MS-DOS.


About this release
------------------

Release 0.9.4:

- new function argument handling
- new exception string values (NameError = 'NameError' etc.)
- better checking for math exceptions
- for sequences (string/tuple/list), x[-i] is now equivalent to x[len(x)-i]
- fixed list assignment bug: "a[1:1] = a" now works correctly

Release 0.9.3:

Release 0.9.3 provides significant new functionality, improves
efficiency, fixes many bugs, and provides increased portability of the
Python interpreter.  The syntax proper has changed only slightly since
0.9.2beta: a new reserved word, 'global', has been added, and there is
new syntax for specifying the base classes in a class declarations.

Highlights of new things in 0.9.3 since 0.9.2:

- string sys.version shows current version (also printed on interactive entry)
- more detailed exceptions, e.g., IOError, ZeroDivisionError, etc.
- 'global' statement to declare module-global variables assigned in functions.
- new class declaration syntax: class C(Base1, Base2, ...): suite
  (the old syntax is still accepted -- be sure to convert your classes now!)
- C shifting and masking operators: << >> ~ & ^ | (for ints and longs).
- C comparison operators: == != (the old = and <> remain valid).
- floating point numbers may now start with a period (e.g., .14).
- definition of integer division tightened (always truncates towards zero).
- new builtins hex(x), oct(x) return hex/octal string from (long) integer.
- new list method l.count(x) returns the number of occurrences of x in l.
- new SGI module: al (Indigo and 4D/35 audio library).
- the FORMS interface (modules fl and FL) now uses FORMS 2.0
- module gl: added lrect{read,write}, rectzoom and pixmode;
  added (non-GL) functions (un)packrect.
- new socket method: s.allowbroadcast(flag).
- many objects support __dict__, __methods__ or __members__.
- dir() lists anything that has __dict__.
- class attributes are no longer read-only.
- classes support __bases__, instances support __class__ (and __dict__).
- divmod() now also works for floats.
- fixed obscure bug in eval('1            ').

These features were new in version 0.9.2beta:

- tutorial now (almost) complete; library reference reorganized
- new syntax: continue statement; semicolons; dictionary constructors;
  restrictions on blank lines in source files removed
- dramatically improved module load time through precompiled modules
- arbitrary precision integers: compute 2 to the power 1000 and more...
- arithmetic operators now accept mixed type operands, e.g., 3.14/4
- more operations on list: remove, index, reverse; repetition
- improved/new file operations: readlines, seek, tell, flush, ...
- process management added to the posix module: fork/exec/wait/kill etc.
- BSD socket operations (with example servers and clients!)
- many new STDWIN features (color, fonts, polygons, ...)
- new SGI modules: font manager and FORMS library interface


Release history
---------------

Version 0.9.0 was posted in February 1991 to alt.sources, soon
followed by patches to bring it up to level 0.9.1.

Compressed tar images of version 0.9.1 was made available for
anonymous ftp on several widely accessible US Internet sites, and in
Europe on hp4nl.nluug.nl and mcsun.eu.net.  Since not everybody has
LaTeX, Postscript of the manuals documentation was also made available
in this way.  Similar for a binhex'ed Macintosh application.

Release 0.9.2 never completely materialized, however a version called
0.9.2beta had limited distribution.  (There was nothing wrong with it
except that I was too busy to release it after it went through beta
testing).



Ftp availability
----------------

I hope to make the compressed tar image of Python available for
anonymous ftp on at least the following sites (the filename being
python0.9.3.tar.Z):

    site            directory

    ftp.cwi.nl        pub        (this is the master source)
    wuarchive.wustl.edu    pub
    uunet.uu.net        tmp


Notes for STDWIN users
----------------------

If you are using STDWIN with Python, you should fetch STDWIN 0.9.6,
available from the same sources as Python -- the new Python provides
interfaces to all the new STDWIN functionality so it won't link if you
use the old STDWIN library.

If you have applied the "unofficial patch" to stdwinmodule.c for the
Sun4 (inserting return keywords before calls to drawing_generic()),
you should unapply that patch, else the new patch may get in trouble.


Overview of this release
------------------------

Here is a summary of the most important user-visible changes in 0.9.2,
in somewhat arbitrary order.  Changes in 0.9.3 are listed in the
"highlights" section above.


1. Changes to the interpreter proper

- Simple statements can now be separated by semicolons.
  If you write "if t: s1; s2", both s1 and s2 are executed
  conditionally.
- The 'continue' statement was added, with semantics as in C.
- Dictionary displays are now allowed on input: {key: value, ...}.
- Blank lines and lines bearing only a comment no longer need to
  be indented properly.  (A completely empty line still ends a multi-
  line statement interactively.)
- Mixed arithmetic is supported, 1 compares equal to 1.0, etc.
- Option "-c command" to execute statements from the command line
- Compiled versions of modules are cached in ".pyc" files, giving a
  dramatic improvement of start-up time
- Other, smaller speed improvements, e.g., extracting characters from
  strings, looking up single-character keys, and looking up global
  variables
- Interrupting a print operation raises KeyboardInterrupt instead of
  only cancelling the print operation
- Fixed various portability problems (it now passes gcc with only
  warnings -- more Standard C compatibility will be provided in later
  versions)
- Source is prepared for porting to MS-DOS
- Numeric constants are now checked for overflow (this requires
  standard-conforming strtol() and strtod() functions; a correct
  strtol() implementation is provided, but the strtod() provided
  relies on atof() for everything, including error checking


2. Changes to the built-in types, functions and modules

- New module socket: interface to BSD socket primitives
- New modules pwd and grp: access the UNIX password and group databases
- (SGI only:) New module "fm" interfaces to the SGI IRIX Font Manager
- (SGI only:) New module "fl" interfaces to Mark Overmars' FORMS library
- New numeric type: long integer, for unlimited precision
    - integer constants suffixed with 'L' or 'l' are long integers
    - new built-in function long(x) converts int or float to long
    - int() and float() now also convert from long integers
- New built-in function:
    - pow(x, y) returns x to the power y
- New operation and methods for lists:
    - l*n returns a new list consisting of n concatenated copies of l
    - l.remove(x) removes the first occurrence of the value x from l
    - l.index(x) returns the index of the first occurrence of x in l
    - l.reverse() reverses l in place
- New operation for tuples:
    - t*n returns a tuple consisting of n concatenated copies of t
- Improved file handling:
    - f.readline() no longer restricts the line length, is faster,
      and isn't confused by null bytes; same for raw_input()
    - f.read() without arguments reads the entire (rest of the) file
    - mixing of print and sys.stdout.write() has different effect
- New methods for files:
    - f.readlines() returns a list containing the lines of the file,
      as read with f.readline()
    - f.flush(), f.tell(), f.seek() call their stdio counterparts
    - f.isatty() tests for "tty-ness"
- New posix functions:
    - _exit(), exec(), fork(), getpid(), getppid(), kill(), wait()
    - popen() returns a file object connected to a pipe
    - utime() replaces utimes() (the latter is not a POSIX name)
- New stdwin features, including:
    - font handling
    - color drawing
    - scroll bars made optional
    - polygons
    - filled and xor shapes
    - text editing objects now have a 'settext' method


3. Changes to the standard library

- Name change: the functions path.cat and macpath.cat are now called
  path.join and macpath.join
- Added new modules: formatter, mutex, persist, sched, mainloop
- Added some modules and functionality to the "widget set" (which is
  still under development, so please bear with me):
    DirList, FormSplit, TextEdit, WindowSched
- Fixed module testall to work non-interactively
- Module string:
    - added functions join() and joinfields()
    - fixed center() to work correct and make it "transitive"
- Obsolete modules were removed: util, minmax
- Some modules were moved to the demo directory


4. Changes to the demonstration programs

- Added new useful scipts: byteyears, eptags, fact, from, lfact,
  objgraph, pdeps, pi, primes, ptags, which
- Added a bunch of socket demos
- Doubled the speed of ptags
- Added new stdwin demos: microedit, miniedit
- Added a windowing interface to the Python interpreter: python (most
  useful on the Mac)
- Added a browser for Emacs info files: demo/stdwin/ibrowse
  (yes, I plan to put all STDWIN and Python documentation in texinfo
  form in the future)


5. Other changes to the distribution

- An Emacs Lisp file "pythonmode.el" is provided to facilitate editing
  Python programs in GNU Emacs (slightly improved since posted to
  gnu.emacs.sources)
- Some info on writing an extension in C is provided
- Some info on building Python on non-UNIX platforms is provided
------------------------------------------------------------------------

Happy hacking Christmas,

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Wenn ist das Nunnstueck git und Slotermeyer?"
"Ja! Beierhund das oder die flipperwaldt gersput."










To: [e-mail]
Subject: Python 0.9.4alpha under the Christmas tree!
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 24 Dec 91 13:20:17 +0100
Sender: guido

After all I think it's better to release 0.9.4 now to see what people
think of it anyway, rather than waiting forever until I find the time
to perfect the documentation (it certainly isn't going to happen over
Christmas).

I've uploaded it to the following three places:

    host            directory

    uunet.uu.net        /tmp
    wuarchive.wustl.edu    /pub
    ftp.cwi.nl        /pub

You should fetch the file python0.9.4alpha.tar.Z.  If you haven't got
STDWIN yet, you can fetch that too, from the same locations; the file
is stdwin0.9.6.tar.Z.  I don't know what's an appropriate place to get
bash/readline from, sorry.

I don't know how long the uunet and wuarchive versions will stay
around; I have some control over ftp.cwi.nl so I think those versions
will stay put, but people in North America should first try either US
site to avoid excessive transatlantic traffic (and Europeans should
try ftp.cwi.nl first!).

Don't ask me to mail it to you; find a friend with Internet ftp access
instead.

Below are the PREFACE and NEWS files from the distribution (directory
misc):

---------------------------------- NEWS --------------------------------
This is the announcement of Python 0.9.4 alpha.  I call it an alpha
release because it is not widely distributed, only to readers of the
Python mailing list, and because the documentation does not yet
describe the new features yet.  However, installation should be
smooth, and I don't expect there are obvious bugs left.

In particular, these changes are not yet documented:

- New class syntax, without extraneous parentheses.
- New 'global' statement to assign global variables from within a function.
- New, more refined exceptions.
- New argument passing semantics.

The release can be picked up by anonymous ftp from site ftp.cwi.nl,
directory pub, file python0.9.4beta.tar.Z.  I will also upload
versions to wuarchive.wustl.edu:/pub and to uunet.uu.net:/tmp.  Please
don't ask me to mail it to you; find a friend with Internet ftp access
instead.

The rest of this file contains explanation for the changes listed above.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Oh Bevis!  And I thought you were so rugged!"


New class syntax
----------------

You can now declare a base class as follows:

    class B:            # Was: class B():
        def some_method(self): ...
        ...

and a derived class thusly:

    class D(B):            # Was: class D() = B():
        def another_method(self, arg): ...

Multiple inheritance looks like this:

    class M(B, D):            # Was: class M() = B(), D():
        def this_or_that_method(self, arg): ...

The old syntax is still accepted by Python 0.9.4, but will disappear
in Python 1.0 (to be posted to comp.sources).


New 'global' statement
----------------------

Every now and then you have a global variable in a module that you
want to change from within a function in that module -- say, a count
of calls to a function, or an option flag, etc.  Until now this was
not directly possible.  While several kludges are known that
circumvent the problem, and often the need for a global variable can
be avoided by rewriting the module as a class, this does not always
lead to clearer code.

The 'global' statement solves this dilemma.  Its occurrence in a
function body means that, for the duration of that function, the
names listed there refer to global variables.  For instance:

    total = 0.0
    count = 0

    def add_to_total(amount):
        global total, count
        total = total + amount
        count = count + 1

'global' must be repeated in each function where it is needed.  The
names listed in a 'global' statement must not be used in the function
before the statement is reached.

Remember that you don't need to use 'global' if you only want to *use*
a global variable in a function; nor do you need ot for assignments to
parts of global variables (e.g., list or dictionary items or
attributes of class instances).  This has not changed; in fact
assignment to part of a global variable was the standard workaround.


New exceptions
--------------

Several new exceptions have been defined, to distinguish more clearly
between different types of errors.

name            meaning                    was

AttributeError        reference to non-existing attribute    NameError
IOError            unexpected I/O error            RuntimeError
ImportError        import of non-existing module or name    NameError
IndexError        invalid string, tuple or list index    RuntimeError
KeyError        key not in dictionary            RuntimeError
OverflowError        numeric overflow            RuntimeError
SyntaxError        invalid syntax                RuntimeError
ValueError        invalid argument value            RuntimeError
ZeroDivisionError    division by zero            RuntimeError

The string value of each exception is now its name -- this makes it
easier to experimentally find out which operations raise which
exceptions; e.g.:

    >>> KeyboardInterrupt
    'KeyboardInterrupt'
    >>>


New argument passing semantics
------------------------------

Off-line discussions with Steve Majewski and Daniel LaLiberte have
convinced me that Python's parameter mechanism could be changed in a
way that made both of them happy (I hope), kept me happy, fixed a
number of outstanding problems, and, given some backward compatibility
provisions, would only break a very small amount of existing code --
probably all mine anyway.  In fact I suspect that most Python users
will hardly notice the difference.  And yet it has cost me at least
one sleepless night to decide to make the change...

Philosophically, the change is quite radical (to me, anyway): a
function is no longer called with either zero or one argument, which
is a tuple if there appear to be more arguments.  Every function now
has an argument list containing 0, 1 or more arguments.  This list is
always implemented as a tuple, and it is a (run-time) error if a
function is called with a different number of arguments than expected.

What's the difference? you may ask.  The answer is, very little unless
you want to write variadic functions -- functions that may be called
with a variable number of arguments.  Formerly, you could write a
function that accepted one or more arguments with little trouble, but
writing a function that could be called with either 0 or 1 argument
(or more) was next to impossible.  This is now a piece of cake: you
can simply declare an argument that receives the entire argument
tuple, and check its length -- it will be of size 0 if there are no
arguments.

Another anomaly of the old system was the way multi-argument methods
(in classes) had to be declared, e.g.:

    class Point():
        def init(self, (x, y, color)): ...
        def setcolor(self, color): ...
        dev moveto(self, (x, y)): ...
        def draw(self): ...

Using the new scheme there is no need to enclose the method arguments
in an extra set of parentheses, so the above class could become:

    class Point:
        def init(self, x, y, color): ...
        def setcolor(self, color): ...
        dev moveto(self, x, y): ...
        def draw(self): ...

That is, the equivalence rule between methods and functions has
changed so that now p.moveto(x,y) is equivalent to Point.moveto(p,x,y)
while formerly it was equivalent to Point.moveto(p,(x,y)).

A special backward compatibility rule makes that the old version also
still works: whenever a function with exactly two arguments (at the top
level) is called with more than two arguments, the second and further
arguments are packed into a tuple and passed as the second argument.
This rule is invoked independently of whether the function is actually a
method, so there is a slight chance that some erroneous calls of
functions expecting two arguments with more than that number of
arguments go undetected at first -- when the function tries to use the
second argument it may find it is a tuple instead of what was expected.
Note that this rule will be removed from future versions of the
language; it is a backward compatibility provision *only*.

Two other rules and a new built-in function handle conversion between
tuples and argument lists:

Rule (a): when a function with more than one argument is called with a
single argument that is a tuple of the right size, the tuple's items
are used as arguments.

Rule (b): when a function with exactly one argument receives no
arguments or more than one, that one argument will receive a tuple
containing the arguments (the tuple will be empty if there were no
arguments).


While no new argument syntax was added in this phase, it would now be
quite sensible to add explicit syntax to Python for default argument
values (as in C++ or Modula-3), or a "rest" argument to receive the
remaining arguments of a variable-length argument list.

-------------------------------- PREFACE -------------------------------
This is Python release 0.9.4 alpha
==================================


What is Python?
---------------

Python is an interpreted prototyping language, incorporating modules,
exceptions, dynamic typing, very high level dynamic data types, and
classes.  Python combines remarkable power with very clear syntax.  It
has interfaces to many system calls and libraries, as well as to
various window systems, and is extensible in C.  It is also usable as
an extension language for applications that need a programmable
interface.  Finally, Python is portable: it runs on many brands of
UNIX, on the Mac, and maybe on MS-DOS.


About this release
------------------

Release 0.9.4:

- new function argument handling
- new exception string values (NameError = 'NameError' etc.)
- better checking for math exceptions
- for sequences (string/tuple/list), x[-i] is now equivalent to x[len(x)-i]
- fixed list assignment bug: "a[1:1] = a" now works correctly

Release 0.9.3:

Release 0.9.3 provides significant new functionality, improves
efficiency, fixes many bugs, and provides increased portability of the
Python interpreter.  The syntax proper has changed only slightly since
0.9.2beta: a new reserved word, 'global', has been added, and there is
new syntax for specifying the base classes in a class declarations.

Highlights of new things in 0.9.3 since 0.9.2:

- string sys.version shows current version (also printed on interactive entry)
- more detailed exceptions, e.g., IOError, ZeroDivisionError, etc.
- 'global' statement to declare module-global variables assigned in functions.
- new class declaration syntax: class C(Base1, Base2, ...): suite
  (the old syntax is still accepted -- be sure to convert your classes now!)
- C shifting and masking operators: << >> ~ & ^ | (for ints and longs).
- C comparison operators: == != (the old = and <> remain valid).
- floating point numbers may now start with a period (e.g., .14).
- definition of integer division tightened (always truncates towards zero).
- new builtins hex(x), oct(x) return hex/octal string from (long) integer.
- new list method l.count(x) returns the number of occurrences of x in l.
- new SGI module: al (Indigo and 4D/35 audio library).
- the FORMS interface (modules fl and FL) now uses FORMS 2.0
- module gl: added lrect{read,write}, rectzoom and pixmode;
  added (non-GL) functions (un)packrect.
- new socket method: s.allowbroadcast(flag).
- many objects support __dict__, __methods__ or __members__.
- dir() lists anything that has __dict__.
- class attributes are no longer read-only.
- classes support __bases__, instances support __class__ (and __dict__).
- divmod() now also works for floats.
- fixed obscure bug in eval('1            ').

These features were new in version 0.9.2beta:

- tutorial now (almost) complete; library reference reorganized
- new syntax: continue statement; semicolons; dictionary constructors;
  restrictions on blank lines in source files removed
- dramatically improved module load time through precompiled modules
- arbitrary precision integers: compute 2 to the power 1000 and more...
- arithmetic operators now accept mixed type operands, e.g., 3.14/4
- more operations on list: remove, index, reverse; repetition
- improved/new file operations: readlines, seek, tell, flush, ...
- process management added to the posix module: fork/exec/wait/kill etc.
- BSD socket operations (with example servers and clients!)
- many new STDWIN features (color, fonts, polygons, ...)
- new SGI modules: font manager and FORMS library interface


Release history
---------------

Version 0.9.0 was posted in February 1991 to alt.sources, soon
followed by patches to bring it up to level 0.9.1.

Compressed tar images of version 0.9.1 was made available for
anonymous ftp on several widely accessible US Internet sites, and in
Europe on hp4nl.nluug.nl and mcsun.eu.net.  Since not everybody has
LaTeX, Postscript of the manuals documentation was also made available
in this way.  Similar for a binhex'ed Macintosh application.

Release 0.9.2 never completely materialized, however a version called
0.9.2beta had limited distribution.  (There was nothing wrong with it
except that I was too busy to release it after it went through beta
testing).



Ftp availability
----------------

I hope to make the compressed tar image of Python available for
anonymous ftp on at least the following sites (the filename being
python0.9.3.tar.Z):

    site            directory

    ftp.cwi.nl        pub        (this is the master source)
    wuarchive.wustl.edu    pub
    uunet.uu.net        tmp


Notes for STDWIN users
----------------------

If you are using STDWIN with Python, you should fetch STDWIN 0.9.6,
available from the same sources as Python -- the new Python provides
interfaces to all the new STDWIN functionality so it won't link if you
use the old STDWIN library.

If you have applied the "unofficial patch" to stdwinmodule.c for the
Sun4 (inserting return keywords before calls to drawing_generic()),
you should unapply that patch, else the new patch may get in trouble.


Overview of this release
------------------------

Here is a summary of the most important user-visible changes in 0.9.2,
in somewhat arbitrary order.  Changes in 0.9.3 are listed in the
"highlights" section above.


1. Changes to the interpreter proper

- Simple statements can now be separated by semicolons.
  If you write "if t: s1; s2", both s1 and s2 are executed
  conditionally.
- The 'continue' statement was added, with semantics as in C.
- Dictionary displays are now allowed on input: {key: value, ...}.
- Blank lines and lines bearing only a comment no longer need to
  be indented properly.  (A completely empty line still ends a multi-
  line statement interactively.)
- Mixed arithmetic is supported, 1 compares equal to 1.0, etc.
- Option "-c command" to execute statements from the command line
- Compiled versions of modules are cached in ".pyc" files, giving a
  dramatic improvement of start-up time
- Other, smaller speed improvements, e.g., extracting characters from
  strings, looking up single-character keys, and looking up global
  variables
- Interrupting a print operation raises KeyboardInterrupt instead of
  only cancelling the print operation
- Fixed various portability problems (it now passes gcc with only
  warnings -- more Standard C compatibility will be provided in later
  versions)
- Source is prepared for porting to MS-DOS
- Numeric constants are now checked for overflow (this requires
  standard-conforming strtol() and strtod() functions; a correct
  strtol() implementation is provided, but the strtod() provided
  relies on atof() for everything, including error checking


2. Changes to the built-in types, functions and modules

- New module socket: interface to BSD socket primitives
- New modules pwd and grp: access the UNIX password and group databases
- (SGI only:) New module "fm" interfaces to the SGI IRIX Font Manager
- (SGI only:) New module "fl" interfaces to Mark Overmars' FORMS library
- New numeric type: long integer, for unlimited precision
    - integer constants suffixed with 'L' or 'l' are long integers
    - new built-in function long(x) converts int or float to long
    - int() and float() now also convert from long integers
- New built-in function:
    - pow(x, y) returns x to the power y
- New operation and methods for lists:
    - l*n returns a new list consisting of n concatenated copies of l
    - l.remove(x) removes the first occurrence of the value x from l
    - l.index(x) returns the index of the first occurrence of x in l
    - l.reverse() reverses l in place
- New operation for tuples:
    - t*n returns a tuple consisting of n concatenated copies of t
- Improved file handling:
    - f.readline() no longer restricts the line length, is faster,
      and isn't confused by null bytes; same for raw_input()
    - f.read() without arguments reads the entire (rest of the) file
    - mixing of print and sys.stdout.write() has different effect
- New methods for files:
    - f.readlines() returns a list containing the lines of the file,
      as read with f.readline()
    - f.flush(), f.tell(), f.seek() call their stdio counterparts
    - f.isatty() tests for "tty-ness"
- New posix functions:
    - _exit(), exec(), fork(), getpid(), getppid(), kill(), wait()
    - popen() returns a file object connected to a pipe
    - utime() replaces utimes() (the latter is not a POSIX name)
- New stdwin features, including:
    - font handling
    - color drawing
    - scroll bars made optional
    - polygons
    - filled and xor shapes
    - text editing objects now have a 'settext' method


3. Changes to the standard library

- Name change: the functions path.cat and macpath.cat are now called
  path.join and macpath.join
- Added new modules: formatter, mutex, persist, sched, mainloop
- Added some modules and functionality to the "widget set" (which is
  still under development, so please bear with me):
    DirList, FormSplit, TextEdit, WindowSched
- Fixed module testall to work non-interactively
- Module string:
    - added functions join() and joinfields()
    - fixed center() to work correct and make it "transitive"
- Obsolete modules were removed: util, minmax
- Some modules were moved to the demo directory


4. Changes to the demonstration programs

- Added new useful scipts: byteyears, eptags, fact, from, lfact,
  objgraph, pdeps, pi, primes, ptags, which
- Added a bunch of socket demos
- Doubled the speed of ptags
- Added new stdwin demos: microedit, miniedit
- Added a windowing interface to the Python interpreter: python (most
  useful on the Mac)
- Added a browser for Emacs info files: demo/stdwin/ibrowse
  (yes, I plan to put all STDWIN and Python documentation in texinfo
  form in the future)


5. Other changes to the distribution

- An Emacs Lisp file "pythonmode.el" is provided to facilitate editing
  Python programs in GNU Emacs (slightly improved since posted to
  gnu.emacs.sources)
- Some info on writing an extension in C is provided
- Some info on building Python on non-UNIX platforms is provided
------------------------------------------------------------------------

Happy hacking Christmas,

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Wenn ist das Nunnstueck git und Slotermeyer?"
"Ja! Beierhund das oder die flipperwaldt gersput."










To: [e-mail] (Hallett German)
Subject: Re: Mac Binary of Python 0.94?
In-reply-to: Your message of "Tue, 24 Dec 91 07:39:32 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 24 Dec 91 13:42:26 +0100
Sender: guido

>Does this bird exist? Thanks for the Xmas present!

Sorry, not yet -- it's very tedious to upload the Python sources to my
Mac at home, and I can't come into the office until Jan. 2 1992...

Cheers,
--Guido van Rossum, CWI, Amsterdam <[e-mail]>
_   /|
\'o.O'
=(___)=
   U










Received: by charon.cwi.nl with SMTP; Thu, 26 Dec 1991 12:48:40 +0100
Received: by voorn.cwi.nl with SMTP; Thu, 26 Dec 1991 11:48:39 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: A script to change to new class syntax
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 26 Dec 91 12:48:38 +0100
Sender: [e-mail]

When I made the 0.9.4alpha release I hadn't fixed the library and demo
programs to use the new class syntax.  Rather than re-issue the
release, here's the Python script I used to convert Python sources to
the new syntax.  Call it with either files or directories as
arguments; it recurses down directories to convert all Python modules
it can find.  It keeps backups of converted files and is cautious
about symbolic links.

The script in itself is an interesting example of recursion down a
directory tree and using regular expressions (the "regexp" module).

Install the script as "demo/scripts/classfix.py".  To convert all
library and demo modules, chdir to the top of the Python tree and
issue this command:

    python demo/scripts/classfix.py lib demo

There is no need to rebuild Python after the script has run.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"No, no really, we're just not religious thank you."

------------------------------- cut here -------------------------------
#! /usr/local/python

# Fix Python source files to use the new class definition syntax,
# i.e.,
#    class C(base, base, ...): ...
# instead of
#    class C() = base(), base(), ...: ...
#
# Command line arguments are files or directories to be processed.
# Directories are searched recursively for files whose name looks
# like a python module.
# Symbolic links are always ignored (except as explicit directory
# arguments).  Of course, the original file is kept as a back-up
# (with a "~" attached to its name).
#
# Undoubtedly you can do this using find and sed, but this is
# a nice example of Python code that recurses down a directory tree
# and uses regular expressions.  Also note several subtleties like
# preserving the file's mode and avoiding to even write a temp file
# when no changes are needed for a file.
#
# Changes made are reported to stdout in a diff-like format.

import sys
import regexp
import posix
import path
import string
from stat import *

err = sys.stderr.write
dbg = err
rep = sys.stdout.write

def main():
    bad = 0
    if not sys.argv[1:]: # No arguments
        err('usage: classfix file-or-directory ...\n')
        sys.exit(2)
    for arg in sys.argv[1:]:
        if path.isdir(arg):
            if recursedown(arg): bad = 1
        elif path.islink(arg):
            err(arg + ': will not process symbolic links\n')
            bad = 1
        else:
            if fix(arg): bad = 1
    sys.exit(bad)

ispython = regexp.compile('^[a-zA-Z0-9_]+\.py$').match # This is a method!

def recursedown(dirname):
    dbg('recursedown(' + `dirname` + ')\n')
    bad = 0
    try:
        names = posix.listdir(dirname)
    except posix.error, msg:
        err(dirname + ': cannot list directory: ' + `msg` + '\n')
        return 1
    for name in names:
        if name in ('.', '..'): continue
        fullname = path.join(dirname, name)
        if path.islink(fullname): pass
        elif path.isdir(fullname):
            if recursedown(fullname): bad = 1
        elif ispython(name):
            if fix(fullname): bad = 1
    return bad

# This expression doesn't catch *all* class definition headers,
# but it's darn pretty close.
classexpr = '^([ \t]*class +[a-zA-Z0-9_]+) *\( *\) *((=.*)?):'
findclass = regexp.compile(classexpr).match # This is a method!

baseexpr = '^ *(.*) *\( *\) *$'
findbase = regexp.compile(baseexpr).match # This is a method, too!

def fix(filename):
##    dbg('fix(' + `filename` + ')\n')
    try:
        f = open(filename, 'r')
    except IOError, msg:
        err(filename + ': cannot open: ' + `msg` + '\n')
        return 1
    head, tail = path.split(filename)
    tempname = path.join(head, '@' + tail)
    tf = None
    # If we find a match, we rewind the file and start over but
    # now copy everything to a temp file.
    while 1:
        line = f.readline()
        if not line: break
        res = findclass(line)
        if not res:
            if tf: tf.write(line)
            continue
        if not tf:
            try:
                tf = open(tempname, 'w')
            except IOError, msg:
                f.close()
                err(tempname+': cannot create: '+`msg`+'\n')
                return 1
            rep(filename + ':\n')
            # Rewind the input file and start all over:
            f.seek(0)
            continue
        a0, b0 = res[0] # Whole match (up to ':')
        a1, b1 = res[1] # First subexpression (up to classname)
        a2, b2 = res[2] # Second subexpression (=.*)
        head = line[:b1]
        tail = line[b0:] # Unmatched rest of line
        if a2 = b2: # No base classes -- easy case
            newline = head + ':' + tail
        else:
            # Get rid of leading '='
            basepart = line[a2+1:b2]
            # Extract list of base expressions
            bases = string.splitfields(basepart, ',')
            # Strip trailing '()' from each base expression
            for i in range(len(bases)):
                res = findbase(bases[i])
                if res:
                    (x0, y0), (x1, y1) = res
                    bases[i] = bases[i][x1:y1]
            # Join the bases back again and build the new line
            basepart = string.joinfields(bases, ', ')
            newline = head + '(' + basepart + '):' + tail
        rep('< ' + line)
        rep('> ' + newline)
        tf.write(newline)
    f.close()
    if not tf: return 0 # No changes

    # Finishing touch -- move files

    # First copy the file's mode to the temp file
    try:
        statbuf = posix.stat(filename)
        posix.chmod(tempname, statbuf[ST_MODE] & 0x7777)
    except posix.error, msg:
        err(tempname + ': warning: chmod failed (' + `msg` + ')\n')
    # Then make a backup of the original file as filename~
    try:
        posix.rename(filename, filename + '~')
    except posix.error, msg:
        err(filename + ': warning: backup failed (' + `msg` + ')\n')
    # Now move the temp file to the original file
    try:
        posix.rename(tempname, filename)
    except posix.error, msg:
        err(filename + ': rename failed (' + `msg` + ')\n')
        return 1
    # Return succes
    return 0

main()










Received: by charon.cwi.nl with SMTP; Thu, 26 Dec 1991 13:22:29 +0100
Received: by voorn.cwi.nl with SMTP; Thu, 26 Dec 1991 12:22:28 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Bugfix for classfix.py
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 26 Dec 91 13:22:27 +0100
Sender: [e-mail]

Oops, the mode in the classfix.py script I just posted to this list was
masked off with a bogus mask.  Here's a patch:

140c140
<         posix.chmod(tempname, statbuf[ST_MODE] & 0x7777)
---
>         posix.chmod(tempname, statbuf[ST_MODE] & 07777)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Antidisestablishmentarianism"










Replied: Sat, 28 Dec 91 17:46:14 +0100
Replied: Tim Peters <[e-mail]>
Replied: [e-mail]
Received: by charon.cwi.nl with SMTP; Sat, 28 Dec 1991 06:03:05 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA03652; Sat, 28 Dec 91 00:03:03 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 000117.25968; Sat, 28 Dec 1991 00:01:17 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA18230; Fri, 27 Dec 91 23:45:15 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA08762; Fri, 27 Dec 91 23:45:14 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Class initialization
Date: Fri, 27 Dec 91 23:45:13 EST
From: Tim Peters <[e-mail]>

>  [guido, replying to steve m]
>  ...
>  Perhaps I could adopt the Modula-3 way (after all I stole enough from
>  M3 already): a built-in function new() with as its first argument a
>  class name and as further arguments the arguments to class's init
>  code.  We also need a way for the user to specify the init code; a
>  function with a standard name ("init" comes to mind :-) seems fine to
>  me.
>  ...

By sheer coincidence I happened to be thinking about that while waiting
at an airport today.  Check out the Python function "new" below:

# module t

class C0():
    def init(self):
        self.att1 = 1
        self.att2 = 2
        self.att3 = 3
        return self
class C1():
    def init(self,(att1)):
        self.att1 = att1
        self.att2 = 2
        self.att3 = 3
        return self
class C2():
    def init(self,(att1,att2)):
        self.att1 = att1
        self.att2 = att2
        self.att3 = 3
        return self
class C3():
    def init(self,(att1,att2,att3)):
        self.att1 = att1
        self.att2 = att2
        self.att3 = att3
        return self

def new(args):
    if type(args) = type(('a','dummy','tuple')):
        Class = args[0]
        Instance = Class()
        return Class.init(Instance, args[1:])
    # just 1 arg, presumably a class
    return args().init()

This works pretty well as is (except ... see later):

>>> from t import *
>>> def dump(x): print x, x.att1, x.att2, x.att3
..
>>> dump( new(C0) )
<instance object at 61b90> 1 2 3
>>> dump( new(C2,[3,4],'cow') )
<instance object at 60210> [3, 4] cow 3
>>> dump( new(C3,'a','b',{'c': 1}) )
<instance object at 60470> a b {'c': 1}

I don't know why, but this just doesn't work as expected for the C1
case:

>>> a = new(C1,0)
>>> a.att1
(0,)
>>>

I.e., the argument list tuple does not get unpacked as I thought it
would.  Similarly:

>>> a,(b) = (1,(2,))  # does not unpack
>>> a
1
>>> b
(2,)
>>> a,(b,) = (1,(2,)) # does unpack
>>> a
1
>>> b
2
>>>

But also

>>> def init(x,(y,)):
Parsing error: file <stdin>, line 1:
def init(x,(y,)):
               ^
Unhandled exception: run-time error: syntax error
>>>

so I can't repair it by changing the declaration of C1's init function
to make clear that the "2nd argument" really is a singleton tuple.

Whatever,

A) My installation of Python is known to suffer from problems that other
   installations don't have (so don't believe the above unless it
   happens to you too).

B) This kind of trick should be easier (more straightforward; more
   uniform) when the argument-clumping semantics are changed as Guido
   described in a later mailing.

C) When a user can program a solution this easily, the case for building
   it into the language is weak.  To the extent that the case for
   building it into the language can still be made, I'd be more inclined
   to see it as pointing at weakness in Python's facilities for
   manipulating methods & functions in general (as opposed to weakness
   in Python's class-initialization facilities specifically).  That is,
   better to go for a general facility than a specific one, and in this
   case Python is at worst "almost there" already.

encouraging-y'all-to-think-of-a-built-in-"new"-as-a-personal-defeat<grin>-
   ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










Received: by charon.cwi.nl with SMTP; Sat, 28 Dec 1991 17:46:13 +0100
Received: by voorn.cwi.nl with SMTP; Sat, 28 Dec 1991 16:46:13 GMT
Message-Id: <[e-mail]>
To: Tim Peters <[e-mail]>
Cc: [e-mail]
Subject: Re: Class initialization
In-Reply-To: Your message of "Fri, 27 Dec 91 23:45:13 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Sat, 28 Dec 91 17:46:11 +0100
Sender: [e-mail]

In response to my thinking-aloud about a built-in new() function to
replace the current class instantiation operation "classname()", Tim
Peters notices that such a new() function is easily defined in Python,
goes on to show how, discovers his solution doesn't quite work, and
wonders why.

Rest assured, this is not a problem with your version of Python: you
have just discovered that the obvious way to create a tuple of one
element (a singleton) doesn't work.  That is:

    >>> a = (1, 2, 3)
    >>> a
    (1, 2, 3)
    >>> b = (1, 2)
    >>> b
    (1, 2)
    >>>

but

    >>> c = (1)
    >>> c
    1
    >>>

If you think about it, the reason is obvious: parentheses are used for
grouping, and you certainly don't want (3+4)*5 to construct a tuple
out of (3+4) -- then the outcome would be (7, 7, 7, 7, 7) instead or 35!

In early Python there were *no* singleton tuples.  I borrowed tuples
from ABC, which also has no singleton tuples, but then added tuple
operations that weren't in ABC, such as subscripting and slicing, and
it became obvious that singletons were a necessity (they could be
created by a slice of length one, for instance).  The solution is not
pretty, but effective: you must write a trailing comma.  With another
small syntactic hack, an empty pair of parentheses can be used to
indicate an empty tuple.

|def new(args):
|    if type(args) = type(('a','dummy','tuple')):
|        Class = args[0]
|        Instance = Class()
|        return Class.init(Instance, args[1:])
|    # just 1 arg, presumably a class
|    return args().init()
|
|This works pretty well as is (except ... see later):

As you noticed, it doesn't work if the class's init function takes
exactly one argument.  The reason is that your call
"Class.init(Instance, args[1:])" always passes a tuple.  The proper
fix is not to change the init function but to make one argument an
exception as well.  Here's my version:

def new(args):
    if type(args) <> type(()):
        args = (args,) # Tuple-ize
    Class = args[0]
    args = args[1:]
    instance = Class()
    if len(args) = 0:
        return instance.init()
    elif len(args) = 1:
        return instance.init(args[0])
    else:
        return instance.init(args)

And just to encourage you to go out and fetch the new release, here's
the version for 0.9.4 -- this is the first case where I found that the
new bulti-in apply() function is handy:

def new(args):
    if type(args) <> type(()):
        args = (args,) # Tuple-ize
    Class = args[0]
    args = args[1:]
    instance = Class()
    return apply(instance.init, args)

I think if you compare the two versions you can see why the new
parameter handling is better.  The initial "if" is still necessary;
maybe there should be extra syntax to indicate that the (remaining)
arguments should be stored as a tuple in the last formal parameter?

|>>> a,(b) = (1,(2,))  # does not unpack
|>>> a
|1
|>>> b
|(2,)
|>>> a,(b,) = (1,(2,)) # does unpack
|>>> a
|1
|>>> b
|2

One could make the point that since parenthesized left-hand sides of
assignments don't make much sense they should always be treated as
tuples.  However, this would lead to inconsistencies:

    >>> (a, b, c)    = (1, 2, 3)    # a=1; b=2; c=3
    >>> (a, b)    = (1, 2)    # a=1; b=2
    >>> (a)        = (1)        # a=1

This currently works as expected, but with that change made the last
statement would be the same error as

    >>> (a,)    = 1

is today.

|>>> def init(x,(y,)):
|Parsing error: file <stdin>, line 1:
|def init(x,(y,)):
|               ^
|Unhandled exception: run-time error: syntax error
|>>>

This was an oversight that will be fixed in version 0.9.5.

|C) When a user can program a solution this easily, the case for building
|   it into the language is weak.

I was proposing it as a *replacement* of the current notation
"Classname()" (i.e., calling a class as if it were a parameterless
function).  I've noticed that it is quite a common mistake to write

    newinstance = Class.init(initialization_arguments)

instead of

    newinstance = Class().init(initialization_arguments)
    #                  ^^

and the error message that is issued in this case is rather confusing,
since "Class.init" is a valid function, only it has one more argument
than is provided...

I'm not saying that a change is absolutely necessary, but I feel that
the current solution is overloading function call with something
rather different.

An alternative is to encourage a programming style where each class
defines its own new() function that creates an instance and
initializes it.  It will still be necessary to separate the init()
function from the new() function, otherwise derived classes wouldn't
have a way to call the base class's init() function.

Anybody else on the list got an opinion?  Should I change the language
or not?

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"That was never five minutes just now!"
"I'm afraid it was."










Received: by charon.cwi.nl with SMTP; Sat, 28 Dec 1991 20:12:12 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa26405;
          28 Dec 91 14:11 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA06975; Sat, 28 Dec 91 14:03:14 EST
Date: Sat, 28 Dec 91 14:03:14 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Syntax for tuples


I recall reading in *some* language description *somewhere* ( perhaps
 it was ML ? )
that ( in that language ) the comma operator was considered the tuple
constructor, and parentheses were only for grouping and forcing it to
be evaluated properly.

Python *almost* behaves like this !
The exception being that the emply tuple is written:
 empty = ()
rather than:
 empty = ,

( But if that *was* ML I was recalling, it uses '()' as the empty tuple or
UNIT value. )

( I don't really know ML, but I'm reading (inspired by some of these discussions)
 David A. Watt's "Programming Language Concepts and Paradigms" which is
 an excellent "sequal" to Bob Tennent's "Programming Language Principles"
 and which ( Wat's book ) uses ML as one of the example languages. )

I *DO* appreciate the argument passing changes - as previously noted, the
code to handle the exceptions required for thezero/one/many functions
were an anoyance ( and I had more trouble getting it right for object
methods ! )

- Steve Majewski










Received: by charon.cwi.nl with SMTP; Sun, 29 Dec 1991 11:02:12 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18687; Sun, 29 Dec 91 05:02:12 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 050116.14399; Sun, 29 Dec 1991 05:01:16 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA23102; Sun, 29 Dec 91 04:36:57 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA04566; Sun, 29 Dec 91 04:36:56 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Python 0.9.4alpha under the Christmas tree!
Cc: [e-mail]
Date: Sun, 29 Dec 91 04:36:55 EST
From: Tim Peters <[e-mail]>

Just FYI:

>  ...
>  I've uploaded it [python0.9.4alpha.tar.Z] to the following three
>  places:
>
>      host            directory
>
>      uunet.uu.net        /tmp
>      wuarchive.wustl.edu    /pub
>      ftp.cwi.nl        /pub

Has not shown up yet on (or has already been deleted from) /tmp on
uunet.uu.net.

Is in wuarchive.wustl.edu's /pub, but is missing src/graminit.h.  Not
sure what I did <grin>, but appeared to successfully worm around that by
uncommenting the graminit rule at the end of the Makefile, doing

    make graminit.h

and then doing a plain "make".

in-any-case-the-best-christmas-present-i-got-today!-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










Replied: Mon, 30 Dec 91 11:25:06 +0100
Replied: Tim Peters <[e-mail]>
Replied: [e-mail]
Received: by charon.cwi.nl with SMTP; Mon, 30 Dec 1991 06:32:12 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18718; Mon, 30 Dec 91 00:32:08 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 003121.21874; Mon, 30 Dec 1991 00:31:21 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA26322; Mon, 30 Dec 91 00:13:22 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA25152; Mon, 30 Dec 91 00:13:21 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Python 0.9.4alpha; Re: Class initialization
Cc: [e-mail]
Date: Mon, 30 Dec 91 00:13:20 EST
From: Tim Peters <[e-mail]>

Congratulations on 0.9.4alpha -- as usual, a very fine piece of work!
Some comments:

>  ...
>  New argument passing semantics
>  ...
>  Two other rules and a new built-in function handle conversion between
>  tuples and argument lists:

The "new built-in function" was not mentioned again in this msg; from
the later "Class initialization" mail I assume it's the new "apply"
built-in.

>  Rule (a): when a function with more than one argument is called with a
>  single argument that is a tuple of the right size, the tuple's items
>  are used as arguments.
>
>  Rule (b): when a function with exactly one argument receives no
>  arguments or more than one, that one argument will receive a tuple
>  containing the arguments (the tuple will be empty if there were no
>  arguments).

Seems to me that Python must have these rules in order to preserve the
equivalence (described in misc/CLASSES) between argument-passing
semantics and the semantics of multiple assignment.  I'm all in favor of
that!

But there are still (at least) two things about variadic functions that
people are certain to trip over (not claiming you don't already realize
this, am claiming I'm not the only one who will notice <grin>):

Oddity #1:

>>> def f(x): print x
..
>>> f(1,2,3)
(1, 2, 3)
>>> f(1,2)
(1, 2)
>>> f(1)
1
>>> f()
()
>>>

That is, passing exactly one argument doesn't fit the pattern:  the
called function does not see a tuple in that (& only in that) case.  I
do *not* want to see that changed, though, because of the useful analogy
with the meanings of

    X = 1, 2, 3  # X is a 3-tuple
    X = 1, 2     # X is a 2-tuple
    X = 1         # X is *not* a tuple
    X = ()         # X is an empty tuple

More on this a bit later.

Oddity #2:

>>> def f(x): print x
..
>>> f()
()
>>> f(())
()
>>>

That is, a variadic function can't distinguish between being called with
no arguments and being called with exactly one argument that happens to
be an empty tuple.  Believe it or not <grin>, I can picture situations
in which this will create a problem; more later.

>  ...
>  - for sequences (string/tuple/list), x[-i] is now equivalent to x[len(x)-i]

Spooky -- you must have read my mind <0.9 grin>.

>  ...
>  - C shifting and masking operators: << >> ~ & ^ | (for ints and longs).

Noted that (the new?) doc/ref.tex says that the operands must be short
integers for all of these operators except for ~.  Noted too that Python
actually accepts longs for all these, so assume your note above is the
real intent.

Want to argue that for longs, the best way to specify these operators is
to (1) treat longs "as if" they were 2's-complement integers with an
unbounded number of sign bits, and (2) that ">>" be arithmetic when
applied to longs (that is, since the string of sign bits is conceptually
infinite, a zero-fill right shift on longs doesn't make sense (as there
is no "left end" for the zero bits to enter)).  If those rules don't
appeal to you instantly, happy to try to justify them.

Python's first cut at this seems rather schizophrenic:

>>> m1 = -1L
>>> m1
-1L
>>> m1a = m1 >> 1  # expect -1L, mostly because nothing else makes sense
>>> m1a           # but prints ~0L
~0L

If longs are modeled as unbounded 2's-comp integers, -1L and ~0L are
both infinite strings of 1's, so I would expect them to be equal:

>>> (m1 = m1a)  # but they compare unequal
0
>>> (m1 = 0), (m1a = 0)  # Python thinks ~0L is equal to 0 (!)
(0, 1)

In some respects m1a *is* acting like 0, but in others it's acting like
an infinite string of 1 bits, and in others ...:

>>> 42 + m1a  # acts like 0 here
42L
>>> 42 & m1a  # acts like binary ...1111...111 here
42L
>>> 42 | m1a  # not sure what to make of this <0.9 grin>
-42L
>>> 42 * m1a  # acts like 0 here
0L
>>> 42 ^ m1a  # curiouser & curiouser ...
32725L

It is a bit tricky, but neither truly hard nor inefficient, to create
the consistent illusion of an infinite string of sign bits; if you agree
it's a good idea, I'd be happy to help with the algorithms.

>  ... [skipping to msg "Re: Class initialization"] ...
>  ... Tim notices that such a new() function is easily defined in
>  Python, goes on to show how, discovers his solution doesn't quite
>  work, and wonders why.
>
>  Rest assured, this is not a problem with your version of Python: you
>  have just discovered that the obvious way to create a tuple of one
>  element (a singleton) doesn't work.

Ha -- you have done me the favor of underestimating my ignorance <smile>.
Turns out that what I actually didn't understand is that when a method
was invoked with one argument

    instance.method(an_argument)

then "method" saw exactly two arguments: the instance object, and
an_argument.  I erroneously *assumed* it would see the instance object
and a singleton *tuple* containing an_argument (in analogy with how,
e.g., after
    instance.method(arg1,arg2)
"method" saw an instance argument and a 2-tuple (arg1,arg2)).  From
there I went on to believe that parentheses in argument lists actually
did force tuple unpacking, and ... garbage in, garbage out.  All your
explanations made sense here, and I'm darned glad you changed the
argument-passing method anyway <grin>.

>  ... [a cleaner "new" that works under the new rules] ...
>  def new(args):
>      if type(args) <> type(()):
>          args = (args,) # Tuple-ize
>      Class = args[0]
>      args = args[1:]
>      instance = Class()
>      return apply(instance.init, args)
>
>  I think if you compare the two versions you can see why the new
>  parameter handling is better.  The initial "if" is still necessary;
>  maybe there should be extra syntax to indicate that the (remaining)
>  arguments should be stored as a tuple in the last formal parameter?

I would like that.  As noted above, the current scheme still contains
some traps for the unwary (one of which is again illustrated in your
"new").  In addition, I suspect that variadic functions are rare enough
that it would help readability/maintenance if the declaration of a
variadic function had a bit of extra syntactic fluff to make it obvious.

How about stealing Icon's gimmick for this?:

    def f(args()): ...
          ^^

The trailing parens here have no meaning in Python now (it's currently a
syntax error), and is meant to say "the arguments (if any) to f are to
be placed in a tuple and stored in 'args'; that tuple will be empty iff
f is invoked without arguments".

Thus
    f()    sets args to the empty tuple ()
    f(())    sets args to the singleton tuple ((),)
    f(1)    sets args to the singleton tuple (1,)
    f(1,2)    sets args to the 2-tuple (1,2)
    etc

This is clean & I believe it's surprise-free (at least I've never been
surprised by it when using Icon's equivalent ...).

Icon actually goes a bit farther and allows any number of "plain"
arguments to precede the (optional) catch-the-rest argument.  E.g.,

    def msg(outfile, tag, strings()):
        outfile.write( tag )
        if len(strings) > 0: outfile.write( ': ' )
        for s in strings: outfile.write( s )
        outfile.write( '\n' )

might be used to define a variadic msg-printer.

The one thing that bothers me about this is weakening the link between
argument-passing and assignment semantics; but perhaps this kind of
notation would also be useful in assignments?  E.g.,

    head, A() = A  # put A[0] in head, & A[1:] in A

There are probably surprises lurking in that, though -- my head is
swimming already <0.9 grin>.  Comments?

>  ...
>  |C) When a user can program a solution this easily, the case for building
>  |   it into the language is weak.
>
>  I was proposing it as a *replacement* of the current notation
>  "Classname()" (i.e., calling a class as if it were a parameterless
>  function).  I've noticed that it is quite a common mistake to write
>
>      newinstance = Class.init(initialization_arguments)
>
>  instead of
>
>      newinstance = Class().init(initialization_arguments)
>      #                  ^^
>
>  and the error message that is issued in this case is rather confusing,
>  since "Class.init" is a valid function, only it has one more argument
>  than is provided...
>
>  I'm not saying that a change is absolutely necessary, but I feel that
>  the current solution is overloading function call with something
>  rather different.

Suggest that the case for making a change got much stronger when the
class syntax changed; that is, now that a class is declared via (e.g.)

    class Derived(Base):

it is much more tempting to fall into the mistake of believing that

    Derived()

means something it doesn't ("hmm, it must be passing an empty tuple
to the 'Base' argument!").

>  ...
>  Anybody else on the list got an opinion?  Should I change the language
>  or not?

Think people need a concrete alternative to pick on.  Since I'm on
vacation this week, I'll volunteer to be the flame absorber <0.9 grin>:

  - The "Class()" notation goes away; you can no longer create a class
    instance that way, & it's an error to try to.  However, class
    attributes continue to work exactly as they work now.

  - A built-in "new(Class_name, optional_arguments)" is introduced for
    creating class instances.  An instance of class Class_name will be
    created.  If the instance does not have a method named (exactly)
    "init", the instance is returned and it is an error if any optional
    arguments were specified.  Else the instance's init method is
    invoked with an argument list composed of the instance and the
    optional arguments (if any) passed to "new", and the result of the
    init method is returned by "new".

  - There is nothing special or unusual about a method named "init"
    except that "new" looks for a method with that name.

  - You want more than that, program it yourself <grin>.

fast-running-out-of-things-to-whine-about-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










To: Tim Peters <[e-mail]>
cc: [e-mail]
Subject: Re: Python 0.9.4alpha; Re: Class initialization
In-reply-to: Your message of "Mon, 30 Dec 91 00:13:20 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 30 Dec 91 11:25:03 +0100
Sender: guido

Tim,

Sorry, I don't have the time to respond to all that (will do later),
but here are a few quick remarks about shifting and masking on long ints.

First, long ints have changes to a *one's complement* representation.
This was the only way that I could give ~0L the meaning of "all 1 bits".
Of course, as soon as you use any arithmetic on it, it changes to 0L,
and arithmetic operations (including unary "-") will never produce it.

Second, there's a bug in the implementation of long &, | and ^ when
one operand is negative and larger than the other; e.g., the outcome
for "1L & ~1000000L" is wrong.  Fixed in 0.9.5.

I hope this explains most of what you've discovered.

"I told you the documentation was out of date :-)"

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"What a senseless waste of human life"










Received: by charon.cwi.nl with SMTP; Mon, 30 Dec 1991 11:25:05 +0100
Received: by voorn.cwi.nl with SMTP; Mon, 30 Dec 1991 10:25:04 GMT
Message-Id: <[e-mail]>
To: Tim Peters <[e-mail]>
Cc: [e-mail]
Subject: Re: Python 0.9.4alpha; Re: Class initialization
In-Reply-To: Your message of "Mon, 30 Dec 91 00:13:20 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 30 Dec 91 11:25:03 +0100
Sender: [e-mail]

Tim,

Sorry, I don't have the time to respond to all that (will do later),
but here are a few quick remarks about shifting and masking on long ints.

First, long ints have changes to a *one's complement* representation.
This was the only way that I could give ~0L the meaning of "all 1 bits".
Of course, as soon as you use any arithmetic on it, it changes to 0L,
and arithmetic operations (including unary "-") will never produce it.

Second, there's a bug in the implementation of long &, | and ^ when
one operand is negative and larger than the other; e.g., the outcome
for "1L & ~1000000L" is wrong.  Fixed in 0.9.5.

I hope this explains most of what you've discovered.

"I told you the documentation was out of date :-)"

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"What a senseless waste of human life"










Replied: Tue, 31 Dec 91 12:36:25 +0100
Replied: Tim Peters <[e-mail]>
Received: by charon.cwi.nl with SMTP; Tue, 31 Dec 1991 06:32:23 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00826; Tue, 31 Dec 91 00:32:21 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 003123.17340; Tue, 31 Dec 1991 00:31:23 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA04475; Tue, 31 Dec 91 00:08:20 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA03104; Tue, 31 Dec 91 00:08:17 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Semantics of long ints
Cc: [e-mail]
Date: Tue, 31 Dec 91 00:08:15 EST
From: Tim Peters <[e-mail]>

>  ... a few quick remarks about shifting and masking on long ints.
>
>  First, long ints have changes to a *one's complement* representation.

That is consistent with some of the samples I posted.

>  This was the only way that I could give ~0L the meaning of "all 1 bits".

?  Don't see a connection.  E.g., it appears that short ints are (as C
greatly favors) represented in 2's-comp, and on this 32-bit machine I get

>>> (~0 = 0xffffffff)
1

That is, ~0 means "all 1's" for short 2's-comp ints, so how could it be
a problem for ~0 to mean "all 1's" for long 2's-comp ints too?  I think
I must be missing your meaning badly.

If the underlying question is "if long ints are unbounded 2's-comp
integers, then how can the ~ operator be implemented such that ~0 works
out to being all 1's (and in all other respects does 'the right
thing')?", the tricky-but-simple answer is "in all cases, ~ should add
1, then flip the sign bit".  That follows from the 2's-comp identity
    -x = ~x + 1
so that
    ~x = -x - 1 = -(x+1)

This assumes that *internally* a signed-magnitude representation is used
for longs (which I believe is true in Python).  Then ~ applied to a 0
will (1) add 1, yielding 1, & (2) flip the sign bit, yielding -1, the
correct 2's-comp way to spell "all 1's".  Similarly, ~ applied to -1
will (1) add 1, yielding 0, & (2) flip the sign bit, again yielding 0,
the correct 2's-comp way to spell "all 0's".  It's not the least charm
of 2's comp that these "spellings" are unique ...


It's clearly easier on the user if short ints & long ints are (at least
conceptually) represented the same way; since C matches nearly all
widely used machines in favoring 2's comp, and Python is implemented in
C, it makes sense for Python to mirror C's rules for short ints.  Using
a different method for long ints will cause inconsistencies, like the
current

>>> 5 & (-1)
5
>>> 5L & (-1L)
4L
>>>

That's not good; e.g., consider the poor user who tries to boost the
precision in their program by switching to long arithmetic and gets
different answers as a result.

>  Of course, as soon as you use any arithmetic on it, it changes to 0L,

Ya, another reason to hate 1's comp <grin>.

>  and arithmetic operations (including unary "-") will never produce it.
>
>  Second, there's a bug in the implementation of long &, | and ^ when
>  one operand is negative and larger than the other; e.g., the outcome
>  for "1L & ~1000000L" is wrong.  Fixed in 0.9.5.
>
>  I hope this explains most of what you've discovered.

Let's see ... The "~0L acts like 0 in arithmetic" explains the results
for the "+" and "*" examples.  The "~0L acts like all 1's" explains the
result for the "&" example.  Believe the "|" and "^" examples remain
mysteries (those don't appear to fit the "one operand is negative and
larger than the other" clause):

>>> 42L | (~0L)
-42L
>>> 42L ^ (~0L)
32725L

Oops, add one more to the pot:

>>> (~0L) << 1  # expected -1L
~0L

>  "I told you the documentation was out of date :-)"

Na, documentation is for wimps -- I wouldn't read it anyway <grin>.

bigints-are-such-a-tricky-business-almost-nobody-gets-them-right-ly y'rs
   - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










Received: by charon.cwi.nl with SMTP; Tue, 31 Dec 1991 15:17:40 +0100
Received: by schelvis.cwi.nl with SMTP; Tue, 31 Dec 1991 14:17:39 GMT
Message-Id: <[e-mail]>
To: Guido van Rossum <[e-mail]>
Cc: [e-mail]
Subject: Re: Steve Majewski's mail
In-Reply-To: Message by Guido van Rossum <[e-mail]> ,
         Tue, 24 Dec 91 12:02:43 +0100 , <[e-mail]>
Organisation: AMOEBA project, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone](home)
X-Last-Band-Seen: Urban Dance Squad (Paradiso), Nozems (Korsakoff, 19-12)
X-Mini-Review: Two *great* gigs in one evening!
Date: Tue, 31 Dec 91 15:17:38 +0100
From: [e-mail]

On the subject of ignoring the object-orientedness in the tutorial:
I don't think this is a good idea. Even a short note about the
reference/value issues (and probably a line saying that the details will
be expained lateron) somewhere early in the manual would have saved
me quite a bit of grief in my first experiences with python.
--
Jack Jansen        | In Holland things are serious, but never hopeless.
[e-mail] | In Ireland things are hopeless, but never serious.
uunet!cwi.nl!jack   G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Received: by charon.cwi.nl with SMTP; Thu, 2 Jan 1992 11:37:24 +0100
X400-Received: by mta relay.surfnet.nl in /PRMD=surf/ADMD=400net/C=nl/; Relayed;
               Thu, 2 Jan 1992 11:36:57 +0100
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Thu, 2 Jan 1992 11:36:18 +0100
X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed;
               Thu, 2 Jan 1992 11:35:50 +0100
Date: Thu, 2 Jan 1992 10:35:50 +0000
X400-Originator: [e-mail]
X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<[e-mail].]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Returned mail...
From: Mail Delivery Subsystem <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Returned mail: Cannot send message for 3 days

   ----- Transcript of session follows -----
421 eaps-mail (ether)... Deferred: Network is unreachable

   ----- Unsent message follows -----
Received: from sun4nl.nluug.nl by eros.uknet.ac.uk via EUnet with SMTP (PP)
          id <[e-mail]>; Mon, 30 Dec 1991 10:28:10 +0000
Received: from charon.cwi.nl by sun4nl.nluug.nl with SMTP;
          id AA23632 (5.65a/CWI-3.1); Mon, 30 Dec 1991 11:27:12 +0100
Received: by charon.cwi.nl with SMTP; Mon, 30 Dec 1991 11:25:05 +0100
Received: by voorn.cwi.nl with SMTP; Mon, 30 Dec 1991 10:25:04 GMT
Message-Id: <[e-mail]>
To: Tim Peters <[e-mail]>
Cc: [e-mail]
Subject: Re: Python 0.9.4alpha; Re: Class initialization
In-Reply-To: Your message of "Mon, 30 Dec 91 00:13:20 MET." <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 30 Dec 91 11:25:03 +0100
Original-Sender: [e-mail]
Sender: [e-mail]

Tim,

Sorry, I don't have the time to respond to all that (will do later),
but here are a few quick remarks about shifting and masking on long ints.

First, long ints have changes to a *one's complement* representation.
This was the only way that I could give ~0L the meaning of "all 1 bits".
Of course, as soon as you use any arithmetic on it, it changes to 0L,
and arithmetic operations (including unary "-") will never produce it.

Second, there's a bug in the implementation of long &, | and ^ when
one operand is negative and larger than the other; e.g., the outcome
for "1L & ~1000000L" is wrong.  Fixed in 0.9.5.

I hope this explains most of what you've discovered.

"I told you the documentation was out of date :-)"

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"What a senseless waste of human life"










To: [e-mail] (Hallett German)
Subject: Re: Mac Binary of Python 0.94?
In-reply-to: Your message of "Tue, 24 Dec 91 07:39:32 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 02 Jan 92 13:19:56 +0100
Sender: guido

>Does this bird exist? Thanks for the Xmas present!

Would you settle for a Mac binary of a 0.9.5 pre-release?  From the README file:

- dictionary objects can now be compared properly; e.g., {}=={} is true
- '==' is now the only equality operator; see demo/scripts/eqfix.py
  for a script that fixes old Python modules
- new exception SystemExit causes termination if not caught;
  it is raised by sys.exit() so that 'finally' clauses can clean up,
  and it may even be caught.  It does work interactively!
- new module "regex" interfaces to GNU Emacs regular expression;
  module "regexp" rewritten in Python for backward compatibility
- formal parameter lists may contain trailing commas

I'll release the sources for 0.9.5 soon (still no up-to-date manual, but I'm
working on it) so I think you'll be better off with a Mac version of that
release anyway.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"It's a bit runny, sir"










Received: by charon.cwi.nl with SMTP; Thu, 2 Jan 1992 21:22:25 +0100
Received: by voorn.cwi.nl with SMTP; Thu, 2 Jan 1992 20:22:24 GMT
Message-Id: <[e-mail]>
To: [e-mail] (Hallett German)
Cc: [e-mail]
Subject: 0.9.5 for the Mac.
In-Reply-To: Your message of "Thu, 02 Jan 92 15:13:01 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 02 Jan 92 21:22:23 +0100
Sender: [e-mail]

For those who wish to try Python on the Mac, I've made a pre-release
version of 0.9.5 for the Mac available by anonymous ftp from site
ftp.cwi.nl, file /pub/Python0.9.5.hqx.  This is just an application
binary; you will still have to fetch UNIX 0.9.4 distribution to get
the library modules.

Here's the list of changes in 0.9.5 compared to 0.9.4, insofar as they
are relevant to the Mac version:

Features:
- dictionary objects can now be compared properly; e.g., {}=={} is true
- new exception SystemExit causes termination if not caught;
  it is raised by sys.exit() so that 'finally' clauses can clean up,
  and it may even be caught.  It does work interactively!
- new module "regex" interfaces to GNU Emacs regular expression;
  old module "regexp" rewritten in Python for backward compatibility
- formal parameter lists may contain trailing commas

Bugs fixed:
- assigning to or deleting a list item with a negative index dumped core
- masking operations involving negative long integers gave wrong results

UNIX source will be made available soon.










Received: by charon.cwi.nl with SMTP; Thu, 2 Jan 1992 23:34:44 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa15611;
          2 Jan 92 17:34 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA09844; Thu, 2 Jan 92 17:25:37 EST
Date: Thu, 2 Jan 92 17:25:37 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re:  0.9.5 for the Mac.
Cc: [e-mail]

Got it!
( Now I can finally python at home, without using my modem ! )

Now I have problems importing modules.
I suppose the way around is to rename:
  macpath.py  --to--> path.py
  maccache.py --to--> dircache.py
 ...etc...

Is this the 'recommended' way, or should I try to
change some of the files to 'conditional' imports ?


I am waiting for a new C compiler ( Borland, instead on MS ) to
be delivered. I am going to be doing some development work on
a PC platform for a change, so I will try to give you a PC port
of python sometime in the near future.

( Yes, I'm back from vacation, so you will be getting some more
  comments on tuples, exceptions, etc. as soon as I have digested
  the new documentation and caught up with Tim & your messages. )


BTW:
 (almost) everything that Tim said in his last series of messages
 goes for me also. I always feel the need to issue some disclaimers
 before writing requests/suggestions/etc. Some are obviously meant
 to make python easier to learn/use ... others are in the aesthetic
 or blue-sky realm ( where opinions often differ ) and an appropriate
 response may be: "Steve, I'll be very interested to see how YOU
 resolve that question when you implement it in STEVE-TRAN/STEVE-BOL/or
 whatever!" :-)

 Please take all the comments as a compliment on the design of python:
 I have found it both practically useful and theoretically interesting.

 - Steve










Replied: Mon, 06 Jan 92 19:32:34 +0100
Replied: [e-mail]
Received: by charon.cwi.nl with SMTP; Mon, 6 Jan 1992 17:55:27 +0100
Received: by meermin.cwi.nl with SMTP; Sat, 4 Jan 1992 02:56:21 GMT
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa02454;
          3 Jan 92 13:19 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA10409; Fri, 3 Jan 92 13:10:44 EST
Date: Fri, 3 Jan 92 13:10:44 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: errors building 0.9.4alpha

In makeing Python 0.9.4 alpha, I get errors on the case statements
in compile.c :

/*###1200 [cc] xor_expr undefined%%%*/
/*###1200 [cc] case expression must be an integer constant%%%*/
/*###1201 [cc] case expression must be an integer constant%%%*/
/*###1201 [cc] and_expr undefined%%%*/
/*###1202 [cc] case expression must be an integer constant%%%*/
/*###1202 [cc] shift_expr undefined%%%*/
/*###1203 [cc] case expression must be an integer constant%%%*/
/*###1203 [cc] arith_expr undefined%%%*/
/*###1851 [cc] global_stmt undefined%%%*/
/*###1851 [cc] case expression must be an integer constant%%%*/
/*###1893 [cc] xor_expr undefined%%%*/
/*###1893 [cc] case expression must be an integer constant%%%*/
/*###1896 [cc] case expression must be an integer constant%%%*/
/*###1896 [cc] and_expr undefined%%%*/
/*###1899 [cc] case expression must be an integer constant%%%*/
/*###1899 [cc] shift_expr undefined%%%*/
/*###1902 [cc] case expression must be an integer constant%%%*/
/*###1902 [cc] arith_expr undefined%%%*/


graminit.h  seems to contain some of the other defines but not
the above.

( grep expr *.h, excluding the uninteresting comment lines ) >>
graminit.h:#define expr_input 258
graminit.h:#define expr_stmt 267
graminit.h:#define expr 289
graminit.h:#define exprlist 295


Anyone else run into this problem ?

- Steve Majewski










Received: by charon.cwi.nl with SMTP; Mon, 6 Jan 1992 19:32:35 +0100
Received: by voorn.cwi.nl with SMTP; Mon, 6 Jan 1992 18:32:33 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: errors building 0.9.4alpha
In-Reply-To: Your message of "Fri, 03 Jan 92 13:10:44 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 06 Jan 92 19:32:32 +0100
Sender: [e-mail]

Steven Majewski writes:

>In makeing Python 0.9.4 alpha, I get errors on the case statements
    ^^^^^^^[sic]
>in compile.c :
>
>/*###1200 [cc] xor_expr undefined%%%*/
>/*###1200 [cc] case expression must be an integer constant%%%*/
[and lots similar]

I bet you extracted 0.9.4 in the same location where 0.9.2 was.

0.9.4 was accidentally distributed without "graminit.[ch]" files,
which I generate lcally whenever I change the syntax, but which the
distributed Makefile believes are part of the distribution.  (Of
course I use my own version of the Makefile :-)

The cure is to get rid of the graminit.[ch] you have and uncomment the
last two non-blank lines of the Makefile.  The next "make" will now
build "pythongen" and run it with "Grammar" as input, producing
correct versions (I sincerely expect and hope).

--Guido van Rossum, CWI, Amsterdam <[e-mail]> Honary Member, Royal
Society for Putting Things on Top of Other Things










Received: by charon.cwi.nl with SMTP; Wed, 15 Jan 1992 14:01:58 +0100
Received: by voorn.cwi.nl with SMTP; Wed, 15 Jan 1992 13:01:57 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Why some things are the way they are in Python
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Wed, 15 Jan 92 14:01:56 +0100
Sender: [e-mail]

In the past few weeks I've had a lot of off-line discussions about
various issues of Python's design with Tim Peters and Steven Majewski.
Longer ago I had similar e-mail exchanges with Daniel LaLiberte.

There was a discussion of variable length argument lists from which I
still have to recover (more about that another time), but there were
also a whole lot of questions raised about other parts of Python's
design.  Rather than repeat my responses over and over again each time
someone raises one such issues again, I've written a little "Socratic"
dialogue that tries to explain why things are the way they are.

The main subjects treated in this dialogue are, roughly:

- why Python has both (immutable) tuples and (mutable) lists
- the rationale behind singleton and empty tuples
- why the parentheses in a function call can't be made optional

It also explains why 'print' is a statement and not a function, and
gives some examples of what you can do with None.


<Q> Why does Python have both tuples and lists?

<A> They serve different purposes.  Lists can get quite long, they are
generally built incrementally, and therefore have to be mutable.
Tuples on the other hand are generally short and created at once.

<Q> Then why can't tuples be mutable and serve both purposes?

<A> Imagine a graphics class that stores coordinates of graphical
objects as tuples.  It may also store rectangles as a tuple of points,
etc.  If tuples were mutable, the class would have to store copies of
all points and rectangles it receives, since otherwise a caller who
creates a point variable, passes its value to the graphics class, and
later changes the point for its own use (e.g., to create another
graphical object with slightly different coordinates) might violate
the internal consistency of the graphics class.  Note that most
callers woouldn't modify the points, but the graphics class has no way
to tell, so it has to make the copies anyway.  (And now imaging the
software is actually layered in such a way that coordinates are passed
down several levels deep...)

<Q> Then why can't lists be made immutable?  There are algorithms and
data structures that guarantee O(log N) or O(N log N)
insert/delete/concatenate/access operations, e.g., B-trees.

<A> This was used in ABC for lists and tables, where I helped
implement it.  My experiences with this were that the code was
incredibly complex and thus difficult to maintain; the overhead for
small lists (which are in the majority in most programs) was
considerable, and the access time for single elements was O(log N).

<Q> Why are there singleton and empty tuples at all in Python?
Wouldn't it be easier to forbid them?  After all special syntax is
used to construct them; this could be removed from the language and
you would have no empty or singleton tuples (like in ABC).

<A> You can also create empty and singleton tuples with slicing
operations.

<Q> But why are slicing operations needed for tuples?  ABC doesn't
have them.

Well, *sometimes* it is useful to treat tuples as sequences of
elements, and use subscripting or slice operations on them.  E.g.,
posix.stat returns an 11-tuple.  Some applications save the first
three elements of such a tuple (mode, inode, device) as a "unique
identifier" for a file.  Slicing (e.g., s[0:3]) is a convenient way of
extracting this.  But using a slice operation it is easy to construct
a singleton tuple (e.g., s[0:1]).

<Q> Then why can't tuple slices that produce singleton tuples be
forbidden or made to return the element instead, so that s[0:1] is the
same as s[0]?

There are many algorithms that can operate on all types of sequences
(tuples, lists and strings) using only subscripting, slicing and
concatenation, and in general these may construct singleton or empty
sequences, if only as intermediate results.  E.g., here's a function
to compute a list of all permutations of a sequence:

    def perm(l):
        if len(l) <= 1: return [l]
        r = []
        for i in range(len(l)):
            p = perm(l[:i] + l[i+1:])
            for x in p: r.append(l[i:i+1] + x)
        return r

For example, perm('abc') is ['abc', 'acb', 'bac', 'bca', 'cab', 'cba']
and perm((1, 2)) is [(1, 2), (2, 1)].  The latter constructs the
singletons (1,) and (2,) internally several times.

<Q> But couldn't tuple concatenation be redefined so that if either
argument were a single value, it would be promoted to a tuple?  Then
tuple slices of one element could return that element, avoiding a
sinleton tuple.

<A> Then perm((1, 2)) above would yield [3, 3]!  Because the final
results are constructing by concatenating the singletons (1,) and
(2,), which would have been replaced by the numbers 1 and 2.

<Q> But what if the concatenation operator were a different symbol
than integer addition, e.g., '++'?

<A> The perm() function would then require the dubious rule that that
1++2 is defined as (1, 2).  Now compare this to 'a'++'b' -- this
obviously means 'ab' (since strings can also be concatenated) but then
the type of a++b would be hard to predict by the reader -- will it be
of the same type as a and b, or will it be the type of (a, b)?  I'm
sure this would cause lots of surprises.

<Q> What about doing it the other way around then?  I.e., singleton
tuples are not automatically degraded to their only element when
created, but when a singleton tuple is the argument of an operation
that requires a plain value, the first and only element of the tuple
is used instead.

<A> Well, the singleton may itself contain a singleton, e.g., ((1,),).
If we degenerate this to its first element we've still got a
singleton, (1,).

<Q> OK, suppose we apply the rule recursively?

<A> It will only confuse for users who wonder whether singletons
actually exist or not.  They conveniently vanish in so many places
that when first learning the language you believe they do not actually
exist.  In other words, the user's model of what's happening will
likely be one of the models rejected earlier, where singletons are
discarded as soon as they are created.  By the time they encounter a
counter-example it will be too late, and they may have written loads
of broken code, like this function to extract the middle element from
a tuple which returns a singleton tuple instead of an element from the
tuple:

    def middle(t):
        i = len(t) / 2
        return t[i:i+1]

The code is broken, but will work for simple examples:

    >>> a = 1, 10, 100, 1000, 10000
    >>> print middle(a) / 2
    50

Only when applied to a tuple containing lists the bug will show up:

    >>> p = []
    >>> q = [1, 10, 100]
    >>> r = range(10)
    >>> b = p, q, r
    >>> for x in middle(b): print x
    [1, 10, 100]

Expected was the same output as from:

    >>> for x in q: print x
    1
    10
    100

<Q> OK, singletons are useful, but why does there have to be this ugly
syntax like (1,) to create them?  Can't you just scrap that and make
slicing the *only* way to create singletons?

<A> Well, tuples have a representation on output, and as long as the
values it contains are simple enough, you can read a tuple as written
back in (with input() or eval()) and get an object with the same
value.  Since singleton tuples exist, they must have a representation
on output, and it is only fair that their representation can also be
read back in.  Also the singleton notation makes it easy to play with
singletons to find out how they work...

<Q> OK, I give up on tuples, they are perfect :-)  Since you mention
the way tuples are written on output, why are they *always* surrounded
by parentheses?  I thought you said that it's not the parentheses but
the comma that makes the tuple...

<A> This makes it easier to write tuples containing tuples.  If the
string representation of all object types is syntactically an atom,
the function for writing a tuple (or converting it to a string, which
uses the same rules) needn't know whether to surround the elements it
writes with parentheses or not.  (ABC uses the latter strategy, which
leads to more code.)

<Q> Oh, and by the way, why isn't print a function?

<A> Because it's such a heavily-used function that it deserves special
treatment -- now that it is a statement, you don't need to type
parentheses around the argument list.  Also, a statement it can use
special syntax to distinguish whether a newline should be appended or
not; if it were a function there would either have to be two functions
(like Pascal's write/writeln) or a special argument value (like "echo
-n" in the Bourne shell).

<Q> Let's shift attention to the function call syntax.  Why can't the
parentheses be optional, like in ABC, so I can write sin x instead of
sin(x)?

<A> And how do I call a function without parameters then?  Does x=f
have to call f if it happens to be a parameterless function, as is the
case in ABC [which has no function pointers] and also in Algol-68
[which does have function pointers, so it calls f except when x is of
type pointer to function]?

<Q> No, assume there are no parameterless functions, but you can
define a function of one argument that is discarded; you can call it
as either f None or f().

<A> Fair enough, although it's not particularly elegant -- I suppose
if I call it as f(1) the argument also gets discarded?  Anyway, what
do you do about the following ambiguity: a[1].  Does this call the
function a with list argument [1], or does it take element 1 of
sequence (list, tuple or string) a?  Surely requiring parentheses
there would only be more confusing:

    >>> def f x: return len x
    >>> a = [1]
    >>> f a
    1
    >>> f [1]
    *** TypeError: subscripting unsubscriptable object

<Q> Can't you resolve this ambiguity at run time, like you already do
for the '+' operator or for the call operator x() (which creates a
class instance if x happens to be a class object)?

<A> I think that would be ugly.  Also I cannot think of a situation
where the user would ever use the ambiguity in a polymorphic function,
unlike for the other two:

    # A function taking either strings or numbers
    def f(a, b):
        if a > b: return a
        else: return a+b

    # A function taking either a class or some other function that
    # creates an instance
    def g(creator):
        for i in range(10):
            instance = creator()
            if instance.acceptable(): return instance
        return None

<Q> What other uses are there for None, besides as return value from a
procedure?

<A> Almost all the same uses that a NULL pointer has in C.  An
important case it the use of None as an error return value (if for
some reason the error doesn' warrant raising an exception), e.g., this
function:

    def openprofile():
        for name in ('.profile', '/etc/Profile', '/usr/etc/Profile'):
            try:
                return open(name, 'r')
            except IOError:
                pass
        return None # No profile -- use default settings

which can be called like this:

    f = openprofile()
    if f:
        <read the profile>
        f.close()

Another use is for a class that may want to postpone creation and
initialization of a subcomponent to the first time it is needed.
E.g.:

    class C:
        def init(self):
            self.sub = None
            return self
        def usesub(self):
            if self.sub is None:
                self.sub = makesub()
            <use self.sub>

None is also useful if a value is required but you aren't interested
in it, e.g., when using the keys of a dictionary to implement a set of
strings:

    class Set:
        def init(self):
            self.dict = {}
            return self
        def add(self, x):
            self.dict[x] = None
        def remove(self, x):
            if self.dict.has_key(x):
                del self.dict[x]
        def ismember(self, x):
            return self.dict.has_key(x)
        # etc.


--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"What a senseless waste of human life"










To: [e-mail]
Subject: a neat/ugly hack
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 16 Jan 92 01:07:00 +0100
Sender: guido

After reading an article by [e-mail] in comp.lang.misc, the
following occurred to me.  Is this net or ugly?  I kinda like it...

It will probably only make sense to you if you've read the file
misc/CLASSES in the Python distribution; it depends on details of
Python's class implementation (which are simple enough, just different
from other OO languages).  It also requires that class objects are
writable (which they are since 0.9.3).

Suppose we have a class whose objects have some kind of state which
modifies the meaning of one or more methods.  Traditionally this is
done by changing a flag which is tested by the affected methods.

Perhaps more efficiency or elegance can be gained by swapping method
pointers.  A naive implementation of this would be the following:

    class C:
        def init(self): ...; return self
        def var1(self): ...
        def var2(self): ...
        def setflag(self): self.var = self.var1
        def clrflag(self): self.var = self.var2
        def usevar(self): ...; self.var(); ...

The problem with this is that it creates circular references, which in
the current version of Python causes uncollectable garbage if the
object becomes unreachable.  (The data attribute self.var is either
self.var1 or self.var2; these aren't plain functions but *method*
objects which, amongst others, contain a pointer (accessible as
im_self) to the object.  If this is still unclear, write me and I'll
explain it in more detail.)

Now the fact that class declarations are executable becomes useful.
We use a function that is supposed to return a new "C" object.  This
function derives a new empty class "C1" from C and initializes it as
if it was a C.  The object can then assign a function to an attribute
of its __class__ and thereby change its methods:

    class C:
        def init(self): ...; return self
        def var1(self): ...
        def var2(self): ...
        def setflag(self): self.__class__.var = C.var1
        def clrflag(self): self.__class__.var = C.var2
        def usevar(self): ...; self.var(); ...

    def newC():
        class C1(C): pass
        return C1().init()

Each call to newC() creates a new class object C1.  This is essential;
if we were to move the definition of C1 out of newC(), calling
setflag() for one C object would change the meaning of var to var1 for
*all* C objects!

There are no circular references in this version: C.var1 and C.var2
are not method objects, they are functions that only get turned into
methods when called as self.var (or self.var1).

A disadvantage of this approach is that it won't work for derived
classes of C.  For some cases this can be solved by passing the class
to be instantiated as a parameter to newC() (which is better renamed to
new() then).  It gets trickier when some derived class also uses this
hack; then that class must take care of the needs of its base class(es).
(This is probably trivial if the hack is used exactly as shown here,
since all base classes can place their switching methods in the same
"C1" class.)

Another disadvantage is that all other method calls become epsilon
slower, since the chain of base classes is one longer.  I haven't
measured this, it should cost no more than one dictionary lookup in a
tiny dictionary.

A variant would require that an instance's __class__ attribute be
writeable (this is currently not the case but it would be a one-line
change to the interpreter); here we would just have two classes C1 and
C2 derived from C and let the setflag() methods switch the instance's
__class__ attribute between C1 and C2.  In fact the mere possibility
of this makes me doubt the read-only-ness of __class__ (or __bases__,
for that matter).

(I wonder if this hack allows one to write Python programs in the
"delegation" paradigm rather than the "inheritance" paradigm.  Or am I
completely off base here?)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"If this is Bolton, I shall return to the pet shop"










Received: by charon.cwi.nl with SMTP; Thu, 16 Jan 1992 01:07:18 +0100
Received: by voorn.cwi.nl with SMTP; Thu, 16 Jan 1992 00:07:01 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: a neat/ugly hack
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 16 Jan 92 01:07:00 +0100
Sender: [e-mail]

After reading an article by [e-mail] in comp.lang.misc, the
following occurred to me.  Is this net or ugly?  I kinda like it...

It will probably only make sense to you if you've read the file
misc/CLASSES in the Python distribution; it depends on details of
Python's class implementation (which are simple enough, just different
from other OO languages).  It also requires that class objects are
writable (which they are since 0.9.3).

Suppose we have a class whose objects have some kind of state which
modifies the meaning of one or more methods.  Traditionally this is
done by changing a flag which is tested by the affected methods.

Perhaps more efficiency or elegance can be gained by swapping method
pointers.  A naive implementation of this would be the following:

    class C:
        def init(self): ...; return self
        def var1(self): ...
        def var2(self): ...
        def setflag(self): self.var = self.var1
        def clrflag(self): self.var = self.var2
        def usevar(self): ...; self.var(); ...

The problem with this is that it creates circular references, which in
the current version of Python causes uncollectable garbage if the
object becomes unreachable.  (The data attribute self.var is either
self.var1 or self.var2; these aren't plain functions but *method*
objects which, amongst others, contain a pointer (accessible as
im_self) to the object.  If this is still unclear, write me and I'll
explain it in more detail.)

Now the fact that class declarations are executable becomes useful.
We use a function that is supposed to return a new "C" object.  This
function derives a new empty class "C1" from C and initializes it as
if it was a C.  The object can then assign a function to an attribute
of its __class__ and thereby change its methods:

    class C:
        def init(self): ...; return self
        def var1(self): ...
        def var2(self): ...
        def setflag(self): self.__class__.var = C.var1
        def clrflag(self): self.__class__.var = C.var2
        def usevar(self): ...; self.var(); ...

    def newC():
        class C1(C): pass
        return C1().init()

Each call to newC() creates a new class object C1.  This is essential;
if we were to move the definition of C1 out of newC(), calling
setflag() for one C object would change the meaning of var to var1 for
*all* C objects!

There are no circular references in this version: C.var1 and C.var2
are not method objects, they are functions that only get turned into
methods when called as self.var (or self.var1).

A disadvantage of this approach is that it won't work for derived
classes of C.  For some cases this can be solved by passing the class
to be instantiated as a parameter to newC() (which is better renamed to
new() then).  It gets trickier when some derived class also uses this
hack; then that class must take care of the needs of its base class(es).
(This is probably trivial if the hack is used exactly as shown here,
since all base classes can place their switching methods in the same
"C1" class.)

Another disadvantage is that all other method calls become epsilon
slower, since the chain of base classes is one longer.  I haven't
measured this, it should cost no more than one dictionary lookup in a
tiny dictionary.

A variant would require that an instance's __class__ attribute be
writeable (this is currently not the case but it would be a one-line
change to the interpreter); here we would just have two classes C1 and
C2 derived from C and let the setflag() methods switch the instance's
__class__ attribute between C1 and C2.  In fact the mere possibility
of this makes me doubt the read-only-ness of __class__ (or __bases__,
for that matter).

(I wonder if this hack allows one to write Python programs in the
"delegation" paradigm rather than the "inheritance" paradigm.  Or am I
completely off base here?)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"If this is Bolton, I shall return to the pet shop"










Received: by charon.cwi.nl with SMTP; Thu, 16 Jan 1992 14:33:04 +0100
Received: by voorn.cwi.nl with SMTP; Thu, 16 Jan 1992 13:33:03 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Getting rid of '\E'
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 16 Jan 92 14:33:01 +0100
Sender: [e-mail]

Currently, Python defines '\E' in string literals as the ASCII ESC
character.  This is the only \-escape that is different from ANSI C.
I have never used it, and that it's actually easy enough to write '\033'.
Would anybody care if I took it out of the language?

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Repo Man's got all night, *every* night"










To: [e-mail]
Subject: Getting rid of '\E'
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 16 Jan 92 14:33:01 +0100
Sender: guido

Currently, Python defines '\E' in string literals as the ASCII ESC
character.  This is the only \-escape that is different from ANSI C.
I have never used it, and that it's actually easy enough to write '\033'.
Would anybody care if I took it out of the language?

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Repo Man's got all night, *every* night"










Received: by charon.cwi.nl with SMTP; Mon, 20 Jan 1992 13:54:22 +0100
Received: by voorn.cwi.nl with SMTP; Mon, 20 Jan 1992 12:54:21 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: should left shift test for overflow?
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 20 Jan 92 13:54:19 +0100
Sender: [e-mail]

Hi folks, after the successful (:-) event of dropping '\E', here I am
again with a microscopic nit in the definition of Python on which I'd
like to see your considered opinion.

I am currently in the process of rationalizing Python's shift and mask
operations.  Long (arbitrary length) integers will pretend they're
using 2's complement notation with an infinite number of bits (e.g., 1
is ...0001, -1 is ...1111, -2 is ...1110, and so on.  This will mean
that any expression involving plain integers that doesn't raise an
exception has the *same* result when one or more of the operands are
replaced by a long integer with the same value.

Currently the only operator for which this isn't the case is left shift.
Bits shifted out of plain (32-bit) integers are dropped mercilessly.
Of course this is done in analogy with C, but it loses the
corrspondence with long integers; e.g., 1000<<25 is -805306368 but
1000L<<25 is 33554432000L.  It also loses the correspondence between
left-shift and multiplication by a power of 2.

But the advantage of dropping the bits is that I can write the
following function to read a 32-bit binary integer from a file:

def rdlongb(f): # Read a "long" (32-bit int) in big-endian format
    s = f.read(4)
    a, b, c, d = ord(s[0]), ord(s[1]), ord(s[2]), ord(s[3])
    return a<<24 | b<<16 | c<<8 | d

If we interpret left-shift as multiplication by a power of 2, the
"a<<24" part would cause overflow if the sign bit of the byte was on
(i.e., if a >= 128).  To fix this, I would have to add something like
"if a >= 128: a = a-256" before the return statement.

Note that the same problem does not exist for right shifts: dropping
bits there is perfectly analogous with division by a power of two
(e.g., 1000>>25 is 0 in any domain).  Also note that I propose to
change integer division of negative numbers such that -1/2 is -1: x/y
is floor(x//y) if x//y means mathematical (loss-less) division, so the
correspondence between (sign-extending) right-shift and division is
perfect.  Modulo will be fixed accordingly: -1%2 will be 1.

My question is, what's more important here: the ability to construct a
negative number by left-shifting a positive number, or correspondence
with long integers and multiplication?

(If you're still with me, you may also tell me if you can find a
reason for unsigned shifts.  I currently plan to make all shift
operations sign-preserving, for correspondence with
multiplication/division with powers of 2.  What are the advantages of
unsigned shifts?)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Programming - the skill (not an art nor a science) of intentional
premature binding.  The best programmers are those who can best make
proper decisions too early." --B. A. Creech, 1969










To: python-list
Subject: should left shift test for overflow?
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 20 Jan 92 13:54:19 +0100
Sender: guido

Hi folks, after the successful (:-) event of dropping '\E', here I am
again with a microscopic nit in the definition of Python on which I'd
like to see your considered opinion.

I am currently in the process of rationalizing Python's shift and mask
operations.  Long (arbitrary length) integers will pretend they're
using 2's complement notation with an infinite number of bits (e.g., 1
is ...0001, -1 is ...1111, -2 is ...1110, and so on.  This will mean
that any expression involving plain integers that doesn't raise an
exception has the *same* result when one or more of the operands are
replaced by a long integer with the same value.

Currently the only operator for which this isn't the case is left shift.
Bits shifted out of plain (32-bit) integers are dropped mercilessly.
Of course this is done in analogy with C, but it loses the
corrspondence with long integers; e.g., 1000<<25 is -805306368 but
1000L<<25 is 33554432000L.  It also loses the correspondence between
left-shift and multiplication by a power of 2.

But the advantage of dropping the bits is that I can write the
following function to read a 32-bit binary integer from a file:

def rdlongb(f): # Read a "long" (32-bit int) in big-endian format
    s = f.read(4)
    a, b, c, d = ord(s[0]), ord(s[1]), ord(s[2]), ord(s[3])
    return a<<24 | b<<16 | c<<8 | d

If we interpret left-shift as multiplication by a power of 2, the
"a<<24" part would cause overflow if the sign bit of the byte was on
(i.e., if a >= 128).  To fix this, I would have to add something like
"if a >= 128: a = a-256" before the return statement.

Note that the same problem does not exist for right shifts: dropping
bits there is perfectly analogous with division by a power of two
(e.g., 1000>>25 is 0 in any domain).  Also note that I propose to
change integer division of negative numbers such that -1/2 is -1: x/y
is floor(x//y) if x//y means mathematical (loss-less) division, so the
correspondence between (sign-extending) right-shift and division is
perfect.  Modulo will be fixed accordingly: -1%2 will be 1.

My question is, what's more important here: the ability to construct a
negative number by left-shifting a positive number, or correspondence
with long integers and multiplication?

(If you're still with me, you may also tell me if you can find a
reason for unsigned shifts.  I currently plan to make all shift
operations sign-preserving, for correspondence with
multiplication/division with powers of 2.  What are the advantages of
unsigned shifts?)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Programming - the skill (not an art nor a science) of intentional
premature binding.  The best programmers are those who can best make
proper decisions too early." --B. A. Creech, 1969










Received: by charon.cwi.nl with SMTP; Tue, 21 Jan 1992 22:26:21 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa10317;
          21 Jan 92 16:26 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA07838; Tue, 21 Jan 92 16:17:19 EST
Date: Tue, 21 Jan 92 16:17:19 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Directory usage tree's in perl & python.


There has been a series of good-perl/bad-perl exchanges in comp.lang.perl,
that produced (among other things) this exchange:

From: [e-mail] (Felix Lee) :

And Perl is definitely awkward with data types.  I haven't yet found a
pleasant way of shoving non-trivial data types into Perl's grammar.
Here's a very simple problem that's tricky to express in Perl: process
the output of "du" to produce output that's indented to reflect the
tree structure, and with each subtree sorted by size.  Something like:
    434 /etc
      |     344 .
      |      50 install
      |      35 uucp
      |       3 nserve
      |       |       2 .
      |       |       1 auth.info
      |       1 sm
      |       1 sm.bak

---


And from:  Tom Christiansen           [e-mail]      convex!tchrist:

:Here's a very simple problem that's tricky to express in Perl: process
:the output of "du" to produce output that's indented to reflect the
:tree structure, and with each subtree sorted by size.  Something like:
:    434 /etc
:      |     344 .
:      |      50 install
:      |      35 uucp
:      |       3 nserve
:      |       |       2 .
:      |       |       1 auth.info
:      |       1 sm
:      |       1 sm.bak

At first I thought I could just keep one local list around
at once, but this seems inherently recursive.  Which means
I need an real recursive data structure.  Maybe you could
do it with one of the %assoc arrays Larry uses in the begat
programs, but I broke down and got dirty.  I think the hardest
part was matching Felix's desired output exactly.  It's not
blazingly fast: I should probably inline the &childof routine,
but it *was* faster to write than I could have written the
equivalent C program.


--tom


#!/usr/bin/perl
# dutree -- [e-mail]

@lines = `du @ARGV`;
chop(@lines);
&input($top = pop @lines);
&output($top);
exit $?;

sub input {
    local($root, *kid, $him) = @_[0,0];
    while (@lines && &childof($root, $lines[$#lines])) {
    &input($him = pop(@lines));
    push(@kid, $him);
    }
    @kid = &sizesort(*kid);
}

sub output {
    local($root, *kid, $prefix) = @_[0,0,1];
    local($size, $path) = split(' ', $root);
    $path =~ s!.*/!!;
    $line = sprintf("%${width}d %s", $size, $path);
    print $prefix, $line, "\n";
    $prefix .= $line;
    $prefix =~ s/\d /| /; $prefix =~ s/[^|]/ /g;
    local($width) = $kid[0] =~ /(\d+)/ && length("$1");
    for (@kid) { &output($_, $prefix); };
}

sub sizesort {
    local(*list, @index) = shift;
    sub bynum { $index[$b] <=> $index[$a]; }
    for (@list) { push(@index, /(\d+)/); }
    @list[sort bynum 0..$#list];
}

sub childof {
    local(@pair) = @_;
    for (@pair) { s/^\d+\s+//g; }
    index($pair[1], $pair[0]) >= 0;
}

---

The above prompted me to try the same problem in python.
First attempt was a simple version, which leads me to discover
that it is an inherently recursively problem ( as Tom states above...
If I could read Perl better without poking into the manual, It might
have been more obvious - I didn't have to perl man with me, so I didn't
try very hard to read it. )

The simple version has 2 problems:
  (1) After writing the python script, I re-read the thread, and saw
      that they had asked for nodes sorted by size, ( at least the terminals,
      I'm not sure if they meant the whole tree. )
      This was just an oversight, BUT I don't see a neat way to
      patch it into this code.
  (2)  "Dangling "|"'s" : This is what made me realize it needs a
      recursize solution.

So back to the drawing board for version 2 :-(
Happy to hear any suggestions!


Simple (version 1) of dutree and output:

#!/usr/local/python
# dutree.py  -- Steven D. Majewski ([e-mail])
# print a directory tree
#

import string,path,posix,sys

# du( root ) ==> [ sorted list of [ path, usage ] ]
def du( root ):
 d = posix.popen('du '+root ,'r' ).readlines()    # slurp up 'du' output
 L = []
 for x in d :
   xx =string.split(x)        # split fields: [ usage, path ],
   xx.reverse()            # swap ( [path,usage] sorts better! )
   L.append( xx )        # append
 L.sort()
 return L

# print L as a tree, where: L = [ sorted list of [ path, usage ] ]
def printdu( L ):
  print L[0]
  comlen = len(string.splitfields( L[0][0], '/' )) + 1
  for x in L[1:]:
     ea = string.splitfields( x[0], '/' ) + x[-1:]
     print (' '*6+'|')*(len(ea)-comlen)+'__',string.rjust(ea[-2],4)+':',ea[-1]
  print '\n'

# tree is defined mainly for interactive use.
# Usage:
# >>>from dutree import tree
# >>>tree( '/usr/local' )
# ( doesn't return anything - only prints tree.)

def tree( root ):
  printdu(du(root))


for d in sys.argv[1:] : tree( d )    # this is main() for dutree.py



--
and sample output:

('/local/lang/Python', '9761')
      |__ demo: 542
      |      |__ scripts: 202
      |      |__  sgi: 176
      |      |      |__   al: 20
      |      |      |__ audio: 4
      |      |      |__ audio_stdwin: 17
      |      |      |__   gl: 69
      |      |      |      |__ glstdwin: 27
      |      |      |__ gl_panel: 64
      |      |      |      |__ apanel: 5
      |      |      |      |__ flying: 30
      |      |      |      |__ nurbs: 9
      |      |      |      |__ twoview: 17
      |      |__ sockets: 17
      |      |__ stdwin: 145
      |      |      |__ ibrowse: 81
      |__  doc: 970
      |__  lib: 382
      |__ local: 86
      |__ misc: 77
      |__ readline: 1107
      |      |__  doc: 256
      |      |__ examples: 14
      |__  src: 2733
      |__ stdwin: 3859
      |      |__ Appls: 227
      |      |      |__  dpv: 84
      |      |      |__ klok: 22
      |      |      |__ miniedit: 45
      |      |      |__ repeat: 9
      |      |      |__ test: 48
      |      |      |__ tetris: 18
      |      |__ Build: 2858
      |      |      |__ sun4: 2857
      |      |      |      |__  x11: 2856
      |      |      |      |      |__ klok: 291
      |      |      |      |      |__  lib: 1647
      |      |      |      |      |__ miniedit: 373
      |      |      |      |      |__ repeat: 291
      |      |      |      |      |__ tetris: 253
      |      |__ Conf: 46
      |      |__  Doc: 146
      |      |      |__  man: 38
      |      |__  Gen: 13
      |      |__    H: 42
      |      |__ Packs: 112
      |      |      |__ textedit: 49
      |      |      |__   vt: 62
      |      |__ Ports: 401
      |      |      |__ alfa: 77
      |      |      |__  mac: 98
      |      |      |__ msdos: 33
      |      |      |__ vtrm: 48
      |      |      |__  x11: 144
      |      |__ Tools: 4

---
Note: ^ the dangling "|" ! :-(
 -- Steve.












Received: by charon.cwi.nl with SMTP; Wed, 22 Jan 1992 08:02:15 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA00770; Wed, 22 Jan 92 02:02:12 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 020131.29377; Wed, 22 Jan 1992 02:01:31 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA22084; Wed, 22 Jan 92 01:37:15 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA10866; Wed, 22 Jan 92 01:37:14 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Directory usage tree's in perl & python.
Cc: [e-mail]
Date: Wed, 22 Jan 92 01:37:13 EST
From: Tim Peters <[e-mail]>

>  [steve m]
>  There has been a series of good-perl/bad-perl exchanges ...
>  ...
>  If I could read Perl better without poking into the manual, It might
>  have been more obvious - I didn't have the perl man with me, ...

Wouldn't have helped <grin> -- seriously, the key to the Perl version is
the "*kid" construction, which is playing games with Perl's internal
symbol tables as a way to fake a "real" data structure.  It's very
tricky stuff, & the Perl book rushes over it, giving only a few trivial
examples after a hand-waving explanation.  Perl wizards all know how to
use it, though -- they don't have much choice <grin/frown>.

> ... they had asked for nodes sorted by size, ( at least the terminals,
> I'm not sure if they meant the whole tree. )

Pretty sure Felix Lee meant the whole tree, at each level.

> ... "Dangling "|"'s" : This is what made me realize it needs a
> recursive solution.

The Perl version also has "dangling |'s", & I *like* them!  Agree
they're hard to get rid of if you really want to; but think Lee had the
"sorted at each level" property in mind when he claimed a natural
advantage for recursive data structures (you need to sort at an
arbitrary number of different levels, without mixing things up across
levels -- hard to do with a flat data structure!).

FYI, I'll attach a different Python stab below.  Notes:

 - This tries to look more like the Perl version in the appearance of
   the output.

 - The Perl version was written to accept an arbitary number of
   directory arguments (@lines = `du @ARGV`), but it actually (in
   effect) ignores all but one of them; the Python version pays
   attention to all of them.

 - When invoked via, e.g., "dutree /dir1/dir2/dir3", the Perl version
   drops the "/dir1/dir2/" portion on the floor by the time it prints
   stuff; the Python version retains it.

 - The Perl version is at least 3x faster than the Python version.  This
   is more my doing than Python's:  I didn't try to take advantage of
   du's output being a postorder traversal, or play any clever tricks
   based on looking for longest matching string prefixes etc.  The sole
   goal I had in writing a Python version was to minimize my own
   programming time, so it's straightforward and the pieces are (in some
   well-hidden <grin> sense) more general than they need to be.  Despite
   that, the Python version turned out to be the same number of lines as
   the Perl version.

 - This is certainly easier to program in Python than in Perl!  The only
   place that felt a little strained was in the sorting, where the
   "size" field had to be the first component so that Python's
   list.sort method would use the size as the primary sort key.  Perl
   does have an advantage here in that its "sort" verb allows specifying
   an arbitrary Perl routine as the comparison predicate; but one could
   code up a similar verb in Python.

   When multiple sub-directories have the same size, my Python version
   lists them in reverse alphabetical order; the Perl version
   effectively lists them in a random order.  Possible to fix either
   version to be nicer about this, but I think it's a bit more strained
   to fix in Python via fooling the built-in "sort".

 - I'm afraid my Python version may be as hard to understand as the Perl
   version.  But hope that's just a side-effect of using complex data
   structures without explaining them <grin>.

   Briefly, the 'suck_up_du' routine constructs a dictionary mapping
   path components into [size, dictionary] pairs, where the contained
   dictionary is again of the same type (mapping the next path
   components into [size, dictionary] pairs, and so on & so on).  This
   makes it very easy to capture the parent-child relationships without
   needing string analysis any fancier than splitting on '/'.

   But Python doesn't have a way to sort dictionaries directly, so the
   "dict2list" function converts the recursive dictionary structure into
   a list of [size, path_component_name, list_of_children] triples,
   where the list_of_children is again of the same (list-of-triples)
   type.  The built-in list.sort() method automatically reorders the
   triples by the "size" field, and a list.reverse() then gets them in
   descending order.  There's also some trickiness to deal with "empty"
   path components arising from my being too lazy earlier to factor out
   longest matching directory prefixes.

   The output routine 'dump' is then a trivial recursive walk over the
   recursive list-of-triples structure.

Example output:

  8161 /lang/work/build/kap/kap12/Python
     |  1605 src
     |   839 readline
     |     |   256 doc
     |     |    14 examples
     |   532 demo
     |     |   206 scripts
     |     |   176 sgi
     |     |     |    69 gl
     |     |     |     |    27 glstdwin
     |     |     |    64 gl_panel
     |     |     |     |    30 flying
     |     |     |     |    17 twoview
     |     |     |     |     9 nurbs
     |     |     |     |     5 apanel
     |     |     |    20 al
     |     |     |    17 audio_stdwin
     |     |     |     4 audio
     |     |   131 stdwin
     |     |     |    67 ibrowse
     |     |    17 sockets
     |   284 lib
     |   189 doc
     |    76 misc
     |    31 local

I strongly encourage anyone comparing Python with Perl to take a whack
at this exercise -- very educational!  Hats off to Mr Lee for a fine
example ...

hoping-to-see-a-better-python-solution-too!-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

#!/usr/local/bin/python

import string, posix, sys

def suck_up_du( dirlist ):
    answer = {}
        for line in posix.popen( 'du ' + dirlist, 'r' ).readlines():
            [size, path] = string.split( line[:-1] ) # chop newline
            size = eval(size)    # convert to int
            insert( answer, path, size )
        return answer

def insert( dict, path, size ):
    components = string.splitfields( path, '/' )
    for chunk in components[:-1]:
        if not dict.has_key( chunk ): dict[chunk] = [-1, {}]
        dict = dict[chunk][1]
    chunk = components[-1]
    if not dict.has_key( chunk ): dict[chunk] = [-1, {}]
    dict[chunk][0] = size

def dict2list( nameprefix, dict ):
    answer = []
    for key in dict.keys():
        [size, kids] = dict[key]
        key = nameprefix + key
        if size < 0:
            for triple in dict2list( key + '/', kids ):
                answer.append( triple )
        else:
            answer.append( [size, key, dict2list('',kids)] )
    answer.sort(); answer.reverse()
    return answer

def dump( prefix, list ):
    for [size,name,kids] in list:
        print prefix + string.rjust(`size`,6), name
        dump( prefix + ' '*5 + '|', kids )

def dudump( dirlist ):
    dump( '', dict2list( '', suck_up_du( dirlist ) ) )

dudump( string.join( sys.argv[1:] ) )

>>> END OF MSG










Replied: Thu, 23 Jan 92 11:36:33 +0100
Replied: "[e-mail] "
Received: by charon.cwi.nl with SMTP; Thu, 23 Jan 1992 00:23:15 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa03387;
          22 Jan 92 18:23 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA09307; Wed, 22 Jan 92 18:14:23 EST
Date: Wed, 22 Jan 92 18:14:23 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: du tree

Thanks, Tim.

Guido also posted a solution to comp.lang.perl. ( In python, that is. )
[ Anyone want it re-posted to the mailing list, or is that redundant
  for this audience. ]

You might also want to post your version ( and your comparison of
perl vs. python ). Then again, you might not. Some of the perl folks
seem to have pretty thin skin when it comes to criticism.

[ There were some references to perl critics as "ankle-biters" !
  Hey - even N.Wirth had to try his hand at designing a half-dozen
  or so languages ... and most of the complaints about Pascal were
  due to the fact that folks were trying to use it for things it
  was never designed for in the first place! ... But I don't think
  Larry Wall himself is as thin skinned as some of his defenders. ]


Another thread for discussion is:
 What is missing from python that is in perl.
 ( Or library - but major features only, i.e. something that is a
   real "application stopper" ! )

My nomination:
  pack/unpack to/from binary structures ( for reading binary files )
  and the python equivalent of 'h2ph' to convert ".h" files into
  a "record description".
  ( I don't *think* there is a way to do this in python. Correct me
    if I'm wrong. )

Any suggestions for a syntax for that routine any different than
the perl equivalent ?  If we exclude longints, the major difference
I see is dealing with possibly recursive structures: lists, tuples
and dictionaries. Should the be disallowed ? ( Probably dictionaries
should be disallowed. ) Should they require a nested format specification ?
How about wildcard lengths for homogeneous sequences ? ( which might
suggest a 'length of previous/next sequence in bytes' specifier ? )

- Steve










Received: by charon.cwi.nl with SMTP; Thu, 23 Jan 1992 11:36:34 +0100
Received: by voorn.cwi.nl with SMTP; Thu, 23 Jan 1992 10:36:33 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: du tree
In-Reply-To: Your message of "Wed, 22 Jan 92 18:14:23 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 23 Jan 92 11:36:33 +0100
Sender: [e-mail]

>Guido also posted a solution to comp.lang.perl. ( In python, that is. )

>You might also want to post your version ( and your comparison of
>perl vs. python ).

I didn't post because I was interested in other people's solutions...
The best solution will make it to the next Python distribution.

>Then again, you might not. Some of the perl folks
>seem to have pretty thin skin when it comes to criticism.

I can cope with that now...

>Another thread for discussion is:
> What is missing from python that is in perl.
> ( Or library - but major features only, i.e. something that is a
>   real "application stopper" ! )
>
>My nomination:
>  pack/unpack to/from binary structures ( for reading binary files )

You can read binary integers using ord() and <<, like the example I
gave in my mail about left shifts.  We use this at CWI to read and
write "AIFF" audio files (an EA-IFF subformat).  What else do you
need?

>  and the python equivalent of 'h2ph' to convert ".h" files into
>  a "record description".
>  ( I don't *think* there is a way to do this in python. Correct me
>    if I'm wrong. )

What's h2ph?  What's a "record description"?  (You can see I'm not a
Perl hacker :-)

>Any suggestions for a syntax for that routine any different than
>the perl equivalent ?  If we exclude longints, the major difference
>I see is dealing with possibly recursive structures: lists, tuples
>and dictionaries. Should the be disallowed ? ( Probably dictionaries
>should be disallowed. ) Should they require a nested format specification ?
>How about wildcard lengths for homogeneous sequences ? ( which might
>suggest a 'length of previous/next sequence in bytes' specifier ? )

(This doesn't make sense to me until I know what h2ph is...)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"May your mailbox overflow with messages" (modern Chinese curse)










Replied: Fri, 24 Jan 92 00:55:37 +0100
Replied: ""Steven D. Majewski" <[e-mail]> +inbox"
Received: by charon.cwi.nl with SMTP; Thu, 23 Jan 1992 20:09:10 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa01766;
          23 Jan 92 14:09 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA09952; Thu, 23 Jan 92 14:00:04 EST
Date: Thu, 23 Jan 92 14:00:04 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: perl pack/unpack


>
> >  and the python equivalent of 'h2ph' to convert ".h" files into
> >  a "record description".
> >  ( I don't *think* there is a way to do this in python. Correct me
> >    if I'm wrong. )
>
> What's h2ph?  What's a "record description"?  (You can see I'm not a
> Perl hacker :-)
>

h2ph converts C ".h" files into Perl ".ph" header files.
#define's & #ifdef's are converted into perl sub-routines.

pack/unpack convert to/from a perl-list <=> (binary) string
according to a TEMPLATE that is sort of like a C or FORTRAN
format string. Something like:

 [ string, int, float1, float2,  float3 ] = unpack( binstr, 'a20Lf3' )


I'm not much of a Perl hacker, either. I was under the mistaken
belief that h2ph also produced pack/unpack templates and/or subroutines
that converted binary C structs into Perl lists. I poked through the
output files in my /usr/local/lib/perl and could not find such a case.
[ I was just starting to learn Perl when I discovered Python. I have
only written a dozen or so simple perl scripts ( enough to get annoyed
with some of Perl's "features" ). *Tim* : As a beginner in both languages,
I can assert that the PYTHON version is MUCH more readable - you are
obviously blinded by your experience with Perl! ) ]

>
> You can read binary integers using ord() and <<, like the example I
> gave in my mail about left shifts.  We use this at CWI to read and
> write "AIFF" audio files (an EA-IFF subformat).  What else do you
> need?

Thanks. I looked at lib/aiff.py.

I think pack/unpack is a convenient interface for the programmer.
( But: can anyone suggest a better way? )

I could wrap up your conversion routines into a higher-level
pack/unpack function. But it might be a reasonable thing to
implement at a lower level. ( C ) - both for effeciency and for
hiding some of the machine differences. [ I'm sure a major use
of this in perl is to build network packets of various sorts :
you need to know if network byte order is the same as native
byte order. ]

The other point I wanted to raise was whether implementing a
perl-like pack/unpack in python ( IN python OR C ) required/
suggested any restrictions or enhancements. The obvious restriction
is to require the input to be a "flat" list: i.e. not containing
other lists, tuples or dictionaries and only containing numbers
and strings ( for this use, strings, although sequences, are
considered simple types - we will not consider lists of strings as
sequences of sequences in this instance. )

[ It would not be difficult to make pack flatten it's input list arg,
or perhaps better, to define a 'format' grammar that expresses
nested-ness, but I think that those "conveniences" might prove to
be error-prone shortcuts. ]


The other thing I believe Perl has, is more elaborate output
formatting & report generation capabilities. But I haven't
actually ever got that far in my Perl programming, so I'm
taking that rumour at face value.

Some of the people in the comp.lang.perl discussion expressed a
wish for a "Perl-2". I would hope that some constructive criticism
from the hard core Perl faithful would be "this (x) is what is lacking
from Python for me to consider it a real substitute for Perl"
( and *NOT* just "I happen to like "@_" , etc. - why use 8 chars when
 2 will do!", and obviously not compatability questions.  )





Follows (LONG) perl pack/unpack man section:





        pack(TEMPLATE,LIST)


Takes an array or list of values  and  packs  it  into  a  binary
structure,  returning  the  string containing the structure.  The
TEMPLATE is a sequence of characters that give the order and type
of values, as follows:

        A       An ascii string, will be space padded.
        a       An ascii string, will be null padded.
        c       A signed char value.
        C       An unsigned char value.
        s       A signed short value.
        S       An unsigned short value.
        i       A signed integer value.
        I       An unsigned integer value.
        l       A signed long value.
        L       An unsigned long value.
        n       A short in network order.
        N       A long in network order.
        f       A single-precision float in the native format.
        d       A double-precision float in the native format.
        p       A pointer to a string.
        x       A null byte.
        X       Back up a byte.
        @       Null fill to absolute position.
        u       A uuencoded string.
        b       A bit string (ascending bit order, like vec()).
        B       A bit string (descending bit order).
        h       A hex string (low nybble first).
        H       A hex string (high nybble first).

Each letter may optionally be followed by a number which gives  a
repeat  count.  With all types except "a", "A", "b", "B", "h" and
"H", the pack function will gobble up that many values  from  the
LIST.   A  * for the repeat count means to use however many items
are left.  The "a" and "A" types gobble just one value, but  pack
it  as  a string of length count, padding with nulls or spaces as
necessary.  (When  unpacking,  "A"  strips  trailing  spaces  and
nulls, but "a" does not.) Likewise, the "b" and "B" fields pack a
string that many bits long.  The "h" and "H" fields pack a string
that many nybbles long.  Real numbers (floats and doubles) are in
the native machine format only; due to the multiplicity of float-
ing  formats around, and the lack of a standard network represen-
tation, no facility for interchange has been  made.   This  means
that packed floating point data written on one machine may not be
readable on another - even if both use IEEE floating point arith-
metic  (as  the  endian-ness  of the memory representation is not
part of the IEEE spec).  Note that perl uses  doubles  internally
for  all numeric calculation, and converting from double -> float
-> double will lose precision (i.e. unpack("f", pack("f",  $foo))
will not in general equal $foo).
Examples:

        $foo = pack("cccc",65,66,67,68);
        # foo eq "ABCD"
        $foo = pack("c4",65,66,67,68);
        # same thing

        $foo = pack("ccxxcc",65,66,67,68);
        # foo eq "AB\0\0CD"

        $foo = pack("s2",1,2);
        # "\1\0\2\0" on little-endian
        # "\0\1\0\2" on big-endian

        $foo = pack("a4","abcd","x","y","z");
        # "abcd"

        $foo = pack("aaaa","abcd","x","y","z");
        # "axyz"

        $foo = pack("a14","abcdefg");
        # "abcdefg\0\0\0\0\0\0\0"

        $foo = pack("i9pl", gmtime);
        # a real struct tm (on my system anyway)

        sub bintodec {
            unpack("N", pack("B32", substr("0" x 32 . shift, -32)));
        }
The same template may generally also be used in the unpack  func-
tion.






        unpack(TEMPLATE,EXPR)


Unpack does the reverse of pack: it takes a string representing a
structure  and  expands it out into an array value, returning the
array value.  (In a scalar context, it merely returns  the  first
value  produced.) The TEMPLATE has the same format as in the pack
function.  Here's a subroutine that does substring:

        sub substr {
                local($what,$where,$howmuch) = @_;
                unpack("x$where a$howmuch", $what);
        }

and then there's

        sub ord { unpack("c",$_[0]); }

In addition, you may prefix a field with a %<number> to  indicate
that you want a <number>-bit checksum of the items instead of the
items themselves.  Default is a 16-bit  checksum.   For  example,
the  following  computes the same number as the System V sum pro-
gram:

        while (<>) {
            $checksum += unpack("%16C*", $_);
        }
        $checksum %= 65536;























Received: by charon.cwi.nl with SMTP; Fri, 24 Jan 1992 10:35:56 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29535; Fri, 24 Jan 92 04:35:50 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 043141.5556; Fri, 24 Jan 1992 04:31:41 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA15733; Fri, 24 Jan 92 04:25:27 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA19265; Fri, 24 Jan 92 04:25:26 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: perl pack/unpack
Cc: [e-mail]
Date: Fri, 24 Jan 92 04:25:25 EST
From: Tim Peters <[e-mail]>

>  [steve m]
>  ... I was under the mistaken belief that h2ph also produced
>  pack/unpack templates and/or subroutines that converted binary C
>  structs into Perl lists. ...

h2ph does what it does, & that's about the only definition you can count
on <frown> -- generally does a reasonable translation of #if[def],
#define of literal constants, & #define of simple macros.  Nearly
everything else (structs, typedefs, declarations, non-trivial macros, is
...) ignored, or mis-translated into Perl that would blow up if it
were invoked.  Provided you don't expect much from it, it's very useful
for getting at the simple stuff.  It would be easy to whip up something
comparable for Python, but one of the secret pitfalls of using a
stronger language is that you're not inclined to settle for doing as
limited a job <0.7 grin>.

>  ... *Tim* : As a beginner in both languages, I can assert that the
>  PYTHON version is MUCH more readable - you are obviously blinded by
>  your experience with Perl!

Sorry, Steve, I did a poor job of writing there.  I fully agree that
Python is both much easier to learn & much easier to read than (typical)
Perl (just "typical" because you don't *have* to use Perl's bottomless
bag of hidden tricks -- think it's quite possible to write Perl that's
as readable as C, it's just that nobody does ...).

I claimed that my program was as hard to *"understand"* as the Perl
version, and understanding covers much more than readability.  I think
two things conspire to make the Python version hard to understand:

1) Felix was disingenuous in calling the problem "very simple" -- it's
   quite involved when you get into the details, and is prone to subtle
   bugs (e.g., the Perl version had several bugs; if you give Guido's
   version more than one directory, it may not sort them correctly at
   the *topmost* level; & I'm not admitting to the bugs in my version
   <grin>).  So much of the "hard to understand" comes from the problem
   itself.  And it may not be apparent from looking at a solution, but
   Python has a strong advantage here in that it supports the kinds
   of data types that more-or-less naturally spring to mind; but that's
   an advantage for the progammer more than it is for the reader.  Which
   leads to ...

2) In my experience, it takes a lot of time for sometime to get
   comfortable with reading code that uses recursive data types in a
   language without declarations & in programs that don't document what
   the data types are.  The Perl version was hideously obscure because
   you just can't tell what "*kid" is being used for without
   understanding the logic completely first; the Python versions were
   similarly obscure (Guido's version was certainly better than mine in
   this respect) in using data types that weren't *obvious* from the
   text.  You really have to dig into the logic to figure out the
   precise inner structure of the various incestuous lists, tuples &
   dictionaries.  I figure the best solution to that is good comments,
   but you can't do that in this example without making it *look* much
   bigger than the (uncommented) Perl version <0.9 grin>.

>  ... [skipping over pack/unpack] ...

>  The other thing I believe Perl has, is more elaborate output
>  formatting & report generation capabilities. But I haven't
>  actually ever got that far in my Perl programming, so I'm
>  taking that rumour at face value.

Perl started life as a report-generating language, & has a very nice
"format" feature (+ lots of associated hair) to support that function
(in essence, you draw a picture of what you want the report to look
like, & Perl takes care of justification & centering & rounding etc the
data to match the picture).

Perl has many features "like that":  unusual hacks that most people never
use but some people use very heavily.  Transparent binding of dbm files
to associative arrays is another of that ilk; for that matter, so are
pack/unpack; the dataflow mechanisms for tracking "unsafe" data derived
from the environment is another; ... Perl simply can't be beat for short
programs that rely on one of those built-in pieces of magic.

seeing-python's-strengths-as-being-overwhelming-but-in-different-areas-ly
   y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










Received: by charon.cwi.nl with SMTP; Tue, 28 Jan 1992 05:32:10 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29023; Mon, 27 Jan 92 23:32:16 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 233138.12555; Mon, 27 Jan 1992 23:31:38 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA15614; Mon, 27 Jan 92 23:08:10 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA27911; Mon, 27 Jan 92 23:08:09 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: One more time on dutree ...
Date: Mon, 27 Jan 92 23:08:08 EST
From: Tim Peters <[e-mail]>

Posted the following to comp.lang.perl; figure there's enough interest
in the Python world to justify sending it to python-list too; feel free
to scream if you disagree.

tersely y'rs  - tim

Newsgroups: comp.lang.perl
Subject: Re: The problems of Perl (Re: Question (silly?))
Summary: use the right tool for the job <grin>
Message-ID: <[e-mail]>
Date: 27 Jan 92 22:41:16 EST
References: <=#[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>

In article <[e-mail]> [e-mail] (Tom Christiansen) writes:
>...
>Larry mentioned to me offline last week that all it takes for this task
>is getting the right sort criteria, and that you needn't use recursion
>or string-munging trickery (the two approaches we've seen) to do it.

By assigning a unique (but otherwise arbitrary) integer ID to each group
of siblings, and using that as the primary sort key (and the du-reported
size as a secondary sort key), only one sort step is needed.  However,
it leaves the records in a bad order for printing (because it makes
siblings adjacent even if they in turn have children).  With more
trickery, a second (stable) sort could fix that.

The parent-child relationships can be captured without recursion and
without string comparisons by noting that:

1) The output of "du dir" is a postorder traversal of the subtree rooted
   at "dir".

2) The number of components in a directory's pathname reliably
   identifies the depth of the directory.

Those clues can be used to build up the tree in a single non-recursive
scan of du's output, just comparing the number of components from one
line to the next.

>Perhaps someone would care to post a solution using that method.

Will attach one that uses recursion only in the output routine & that
restricts itself to "flat" (non-recursive) data types.  Even so, I wrote
it in Python because it's still clumsier in Perl.  And I think this was
Felix Lee's original point:  while it's amusing to think of ways to twist
the problem to fit comfortably into Perl's repertoire, the *obvious* way
to attack a tree-based algorithm is to use recursive data types, so that
trying to use a language that doesn't support them changes the focus of
the effort from solving the problem to wrestling with the language.  For
this reason, as an old-time Fortran programmer I am sometimes overcome
by deja vu when using Perl <0.7 grin>.

BTW, this is not intended as a knock at Perl!  I use Perl dozens of
times each day & believe it's superbly suited to many real-world tasks.
There are, however, many real-world tasks (like this one) for which Perl
is about the last tool I'd choose.


Some notes on the code below:

  - This inserts a '.' entry as needed to suck up otherwise-unaccounted-
    for space.

  - The paths at the top level are printed out in full.

  - It works correctly if more than one directory is given on the
    command line (Tom's original program printed only the last one in
    this case, and Guido's sometimes got the sorting wrong at (just) the
    topmost level in this case).

  - When two or more siblings have the same size, this version prints
    them in alphabetical order.  This was my intent, but you won't see
    any code specifically arranging for that to happen -- it happens by
    magic because of the way Python defines ordering on tuples.

  - Unlike the other programs, this one does *not* try to vary the
    indentation depending on the length of a component name.  I simply
    dislike the way the output looks when that's done, and much prefer a
    fixed indentation increment.

  - The sorting is done as it goes along (rather than using the trick
    mentioned above to do it all at once) just because that's the most
    natural way to do it; it would be clumsier to push the sorting off
    to the end.

  - The primary data structure is the associative array 'kids', which
    has type (making up a type-decl notation here ...)

    array[string] of list of triple(int,string,string)

    I know it isn't hard to fake such a thing in Perl, but it does take
    some tedious trickery not needed in Python.  That's the "deep"
    reason I think Python (or Icon) is a better tool for this problem:
    it consumes less of *my* time to get the job done (& I prefer Perl
    for problems where Perl is less hassle ...).

if-i-wanted-speed-i'd-write-it-in-fortran<grin>-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

#!/usr/local/bin/python
import string, posix, sys

leadering = '      |'

def suck_up_du( dir ):
    # 'kids' maps a pathname to a flat list of the pathname's children;
    # each entry in the list is a triple:
    #     size of child (negated so it sorts in decreasing order)
    #      last component of child's pathname (cached for output)
    #      child's full pathname (used to index back into 'kids')
    global kids

    a, total, leftover, oldncomps = [], 0, {}, 0
    for line in posix.popen( 'du ' + dir, 'r' ).readlines():
    [size, path] = string.split( line )
    size = eval(size) # convert to int
    comps = string.splitfields( path, '/' )
    ncomps = len(comps)
    if ncomps < oldncomps:  # line is parent
        if total < size: a.append( (total-size, '.', path+'/.') )
        a.sort()
        kids[path] = a
        oldncomps = ncomps
        try: a, total = leftover[`ncomps`]
        except KeyError: a, total = [], 0
        leftover[`ncomps`] = [], 0
    elif ncomps > oldncomps:  # line starts new subtree
        leftover[`oldncomps`] = a, total
        a, total, oldncomps = [], 0, ncomps
    a.append( (-size, comps[-1], path) ) # negate size for sort
    total = total + size
    return a[0]

def dump( prefix, list ):
    for size, last, path in list:
    print prefix + string.rjust(`-size`,lenlead), last
    if kids.has_key(path): dump( prefix + leadering, kids[path] )

def dudump( dirlist ):
    global kids, lenlead
    kids, a, lenlead = {}, [], len(leadering)
    for dir in dirlist:
    size, junk, path = suck_up_du( dir )
    a.append( (size,path,path) ) # display full path at top level
    a.sort()
    dump( '', a )

dudump( sys.argv[1:] or [''] )

>>> END OF MSG










Received: by charon.cwi.nl with SMTP; Thu, 30 Jan 1992 22:56:54 +0100
Received: by relay.CDNnet.CA (4.1/1.14)
    id AA20620; Thu, 30 Jan 92 13:56:11 PST
Date: 30 Jan 92 13:50 -0800
From: John Buchanan <[e-mail]>
To: <[e-mail]>
Message-Id: <1783*[e-mail]>
Subject: installing python 0.9.4alpha


I am not sure whether this goes here on in some other list but what the heck.

I got the python and stdwin archives from wuarchive.wustl.edu.  They
installed very nicely on sgi sparc architectures.  They also installed on an
IBM but with a little of work on the stdwin side.

In the Conf directory of the stdwin directory structure I had to make a new file
proto.arch.aix and I had to place a dummy 'arch' program in my path.  After
I did this installing with
    ./mkmf -o aix

worked nicely.










Received: by charon.cwi.nl with SMTP; Tue, 4 Feb 1992 06:32:20 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA14254; Tue, 4 Feb 92 00:32:25 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 003133.29439; Tue, 4 Feb 1992 00:31:33 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA15056; Mon, 3 Feb 92 22:32:25 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA27065; Mon, 3 Feb 92 22:32:24 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: An improved Emacs Python mode
Date: Mon, 03 Feb 92 22:32:24 EST
From: Tim Peters <[e-mail]>

You might want to give the following a try in place of
Python/misc/python.el.

Major enhancements:

  - Honors your choice of indentation increment.

  - Less naive about when to indent.  E.g., will not indent after
    a = b   # ok: # found
    or
    a = ': #'
    In the absence of continuation lines, I don't believe this version
    will ever get it wrong (so please send an example if it does).

Details:

  - Suggest you install this as python-mode.el (the Python distribution
    names it 'python.el', but the '-mode' suffix is a universal
    convention for Emacs language modes).  This will require that you
    change your .emacs to say
    (autoload 'python-mode "python-mode" "" t)
    instead of the current
    (autoload 'python-mode "python" "" t)

  - As written, the indentation increment defaults to 4 columns, just
    because that's what I seem to like best for Python code.  Change the
    variable py-indent-offset to whatever you want it to be; e.g., to be
    compatible with the current python.el, which always indents by full
    tabs, stick this in your .emacs file:
    (setq py-indent-offset 8)

  - "Unindenting" a line is still done via the DEL key, but the DEL key
    is now smarter:  it will "dedent" the line by py-indent-offset
    columns if point happens to be at the first non-blank character of a
    line (or at the end of an entirely blank line), else it will delete
    just the preceding character (& convert tabs to spaces if needed, so
    that just 1 column position will be deleted).

    I worried that this interface might be too much of a hack, but in
    practice I've found it to be quite natural.  If you have a better
    idea, or find it too surprising or confusing, please holler.

  - Still no effective support for continuation lines (this is all
    driven by what bugs me when I'm writing code, & I simply haven't had
    a need for a continuation line yet hence didn't worry about 'em).

  - Changed the mode documentation (C-h m) to warn against using
    indent-region, and to suggest using indent-rigidly for shifting a
    block of Python code.  One thing I would like to do is add some
    shortcut support for marking & shifting regions of Python code;
    indent-region will never be able to figure out what you wanted
    (think about it <grin>), so after cutting a piece of Python code out
    of one file & pasting it into a new context, it can be quite a pain
    to figure out how to get the indentation right for the new context.
    It should be possible for Python-mode to give the user some help
    with this (e.g., something as simple as "'C-c <' shifts the region
    left by py-indent-offset columns, and 'C-c >' shifts it right
    similarly" would, I think, be helpful).

If there's something that you think would help you often & a lot in
Python mode, drop me a note & maybe I'll find the time to try & hack it
in.

just-another-aggressive-member-of-the-python-youth-corps-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

;; Major mode for editing Python programs.
;; by: Michael A. Guravage and Guido van Rossum <[e-mail]>
;;
;; The following statements, placed in your .emacs file or site-init.el,
;; will cause this file to be autoloaded, and python-mode invoked, when
;; visiting .py files (assuming the file is in your load-path):
;;
;;    (autoload 'python-mode "python-mode" "" t)
;;    (setq auto-mode-alist
;;          (cons '("\\.py$" . python-mode) auto-mode-alist))

;; Change log:
;
; Sun Feb  2 02:08:47 1992  tim
; added support for user-defined indentation increment:
;     added python-indent variable
;    changed py-indent-line to indent python-indent columns
;    fixed small bug in py-indent-line (changed start of r.e.
;        from [^#] to [^#\n])
;    added py-delete-char function; bound to \177
;    changed mode blurb accordingly
;
; Sun Feb  2 21:48:59 1992  tim
; renamed 'python-indent' to 'py-indent-offset' for internal consistency
; replaced regexp in py-indent-line so it no longer indents after
;    lines like:
;    a = b   # ok: # found
;    a = ': #'
;
; Mon Feb  3 20:37:27 1992  tim
; renamed file to 'python-mode.el' for consistency with other Emacs
;    language modes; changed autoload instructions accordingly
; improved accuracy of new/changed docs
; changed py-python-command from defconst to defvar so .emacs can
;    override it if desired
; add warning about indent-region; suggest indent-rigidly

(provide 'python)

;; Constants and variables

(defvar py-python-command "python"
  "*UNIX shell command used to start Python interpreter")

(defvar py-indent-offset 4
  "*Indentation increment in Python mode")

(defvar py-mode-map nil
  "Keymap used in Python mode buffers")

(defvar py-mode-syntax-table nil
  "Python mode syntax table")


;; Initialize the keymap if it doesn't already exist

(if (null py-mode-map)
    (progn
      (setq py-mode-map (make-sparse-keymap))
      (define-key py-mode-map "\C-c\C-c" 'py-execute-buffer)
      (define-key py-mode-map "\C-c|"     'py-execute-region)
      (define-key py-mode-map "\C-c!"     'py-shell)
      (define-key py-mode-map "\177"     'py-delete-char)))

;; General Functions

(defun python-mode nil
  "Major mode for editing Python files.

\\[py-execute-buffer] sends the entire buffer to the Python interpreter.
\\[py-execute-region] sends the current region.
\\[py-shell] starts a Python interpreter window; this will be used by
subsequent \\[py-execute-buffer] or \\[py-execute-region] commands.


Variable py-indent-offset is the indentation increment.

\\[newline-and-indent] indents by an extra py-indent-offset columns where
necessary.  Use \\[py-delete-char] to reduce indentation.

\\[py-delete-char] reduces the indentation of a line by py-indent-offset columns
if point is at the first non-blank character (if any) of a line, or at
the last character of an entirely blank line; else it deletes the
preceding character, converting tabs to spaces as needed so that only
one character position is deleted.

Warning:  indent-region should not be used!  Use indent-rigidly to shift
regions of Python code instead.  indent-region can't guess the
indentation you had in mind, and will, e.g., change

    xxx
    if a = b:
        c = d
    if e = f: print 'ouch!'

to
    xxx
    if a = b:
        c = d
        if e = f: print 'ouch!'

Paragraphs are separated by blank lines only.
\\{py-mode-map}
\\[python-mode] calls the value of the variable py-mode-hook with no args,
if that value is non-nil."
  (interactive)
  (kill-all-local-variables)
  (use-local-map py-mode-map)
  (setq major-mode 'python-mode)
  (setq mode-name "Python")
  (if py-mode-syntax-table
      (set-syntax-table py-mode-syntax-table)
    (progn
      (setq py-mode-syntax-table (make-syntax-table))
      (set-syntax-table py-mode-syntax-table)
      (modify-syntax-entry ?\( "()")
      (modify-syntax-entry ?\) ")(")
      (modify-syntax-entry ?\[ "(]")
      (modify-syntax-entry ?\] ")[")
      (modify-syntax-entry ?\{ "(}")
      (modify-syntax-entry ?\} "){")
      (modify-syntax-entry ?\_ "w")
      (modify-syntax-entry ?\' "\"")    ; single quote is string quote
      (modify-syntax-entry ?\` "$")    ; backquote is open and close paren
      (modify-syntax-entry ?\# "<")    ; hash starts comment
      (modify-syntax-entry ?\n ">")    ; newline ends comment
      ))
  (make-local-variable 'paragraph-separate)
  (setq paragraph-separate "^[ \t\f]*$")
  (make-local-variable 'paragraph-start)
  (setq paragraph-start "^[ \t\f]*$")
  (make-local-variable 'require-final-newline)
  (setq require-final-newline t)
  (make-local-variable 'comment-start)
  (setq comment-start "# ")
  (make-local-variable 'comment-start-skip)
  (setq comment-start-skip "# *")
  (make-local-variable 'comment-column)
  (setq comment-column 40)
  (make-local-variable 'indent-line-function)
  (setq indent-line-function 'py-indent-line)
  (run-hooks 'py-mode-hook))


;; Functions that execute Python commands in a subprocess

(defun py-shell nil
  "Start an interactive Python interpreter in another window.
The variable py-python-command names the interpreter."
  (interactive)
  (require 'shell)
  (switch-to-buffer-other-window
   (make-shell "Python" py-python-command))
  (make-local-variable 'shell-prompt-pattern)
  (setq shell-prompt-pattern "^>>> \\|^\\.\\.\\. "))

(defun py-execute-region (start end)
  "Send the region between START and END to a Python interpreter.
If there is a *Python* process it is used."
  (interactive "r")
  (condition-case nil
      (process-send-string "Python" (buffer-substring start end))
    (error (shell-command-on-region start end py-python-command nil))))

(defun py-execute-buffer nil
  "Send the contents of the buffer to a Python interpreter.
If there is a *Python* process buffer it is used."
  (interactive)
  (py-execute-region (point-min) (point-max)))


;; Functions for Python style indentation

(defun py-indent-line nil
  "Fix the indentation of the current line according to Python rules."
  (interactive)
  (backward-to-indentation 1)
  (let ( (ci (current-indentation)) )
    (if (looking-at
     "\\([^#'\n]\\|'\\([^'\n\\\\]\\|\\\\.\\)*'\\)*:[ \t]*\\(#.*\\)?$")
    (setq ci (+ ci py-indent-offset)))
    (forward-line 1)
    (delete-horizontal-space)
    (indent-to ci)))

(defun py-delete-char nil
  "If at first non-blank character, or at last character of blank line,
reduce indentation by the value of variable py-indent-offset.  Else
delete preceding character, converting tabs to spaces."
  (interactive)
  (backward-delete-char-untabify
   (if (and
    (= (current-indentation) (current-column))
    (>= (current-indentation) py-indent-offset))
       py-indent-offset
     1)))

;; To do:
;; - proper indentation for continuation lines
;; - add a newline when executing buffer ending in partial line
;; - suppress prompts when executing regions
;; - switch back to previous buffer when starting shell
;; - support for ptags

>>> END OF MSG










Replied: Wed, 05 Feb 1992 00:14:20 +0100
Replied: [e-mail]
Received: by charon.cwi.nl with SMTP; Tue, 4 Feb 1992 22:05:59 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa29078;
          4 Feb 92 16:05 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA05826; Tue, 4 Feb 92 15:56:25 EST
Date: Tue, 4 Feb 92 15:56:25 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Python portability planning ( and prototypes ) [ pwas: pack/unpack...]

In discussion with guido ( mostly about pack/unpack from binary records )
I suggested a sys.arch variable be added to module sys to contain machine
or os specific info.

[ Guido: I DO have some more specific followups on some of the other
  questions/issues, but I, too, have been busy with other things. I've
  been sitting on this os module waiting for time to move all the sources
  to my PC and start on the dos end of things. ]


me> The pack/unpack proposal was just meant as something for discussion.
me> I am now serious about 'sys.arch' as a proposal.

To which guido responded:

Guido> But what value would you like sys.arch to have, and how would you
Guido> choose the right value at compile time?  An an alternate proposal, I
Guido> can implement an interface to the Posix uname() function; this returns
Guido> a system name, a node (host) name, a release level, a version level
Guido> (of the release), and a machine type.  I suppose this is easy enough
Guido> to fake for systems that don't have full Posix libraries yet.  For
Guido> now, you can fake this by doing something like
Guido> string.split(posix.popen('uname -a', 'r')), provided you have the
Guido> uname program.  Older systems may have a utility called arch (SunOS)
Guido> or machine (Ultrix), I'm sure you can cook up a function which tries
Guido> several of these until it finds one which works.

Well, that's the reason I brought up the subject. I *DIDN'T* in any
sense mean to infer that most of these things couldn't be done in python
( rather than coded in C to provide a python-interface ), but since they
all address portability concerns, they seem to indicate to me that
EITHER they should be "builtins" to the language ( and defined in the
library manual ) OR they should be declared "conventions" ( i.e. "this
is the proper way to do this in python, and therefore you had better not
do *X* because that will make your code horribly un-portable." )

So, I'm only partially asking a "how-to" question.
The more important question is the "how-should" question.

 I am also *not* discussing things that should be C-source coded ( rather
than Python-source coded ) for effeciency. There probably are some cases
but there it makes sense to try out a python prototype BEFORE considering
a "native code" solution.

But there are some other things that either are not do-able *directly*
in python, or are relatively difficult to provide in python, but easier
to provide in C-source as python "built-in's".

 The base level determination now seems to be that you can tell (roughly)
what os you are on by which "import" statement succeeds. [ *Is* this the
only way ? I think so. ]. If "import mac" succeeds, the we know we are
on a  mac, and can assume that the CPU is a m680x0 type, and we can
have a dictionary of CPU's and endian-ness-flags, etc. But if/when apple
ships Risc-Mac's the library routines need to be changed. It doesn't seem
any more of a bother to require some #define's/#ifdef's in a config.h
file that pre-define some of these. Using the 'succesful import' rule
for determining machine variables also means that the convention must
be enforced of "no modules named "dos", "mac", "posix" , etc. This means
that you can't provide (limited) posix or dos functionality to another
system by an "external" posix module ( or dos.py ) because that will
make 'import posix' succeed on the wrong machine, and may interfere with
other routines that need it to fail to determine machine specific parameters.
( And forcing "import posix" to really "import mac" seems the only way
to make the library sources backward compatible! ( or "path" & "macpath" )

Back to the question of *what* needs to be "pre-defined" -
I'm not really sure.
 We should start off with a minimal set of what can be easily
determined either by the compiler or edited into a config.h file.
(1) I think (dos|posix|mac|whatever) should be #define-d in, and *not*
    determined by successful import.
(2) I think cpu-family should also be determined at compile time.
    [ Exactly which cpu ( 80286 vs 80386, 68000 vs 68020, etc. )
     CAN NOT be determined by the compiler ( except for the non-downward
     compatible cases - gnu C will *only* produce 32 bit 386,486 code. )
     And I can't really thing of a use for this info except as a potential
     warning to folks stuck with only a 640K python on a PC. I expect they'll
     get SOME sort of run time message when alloc/malloc fails ]
/* the above are my "must" list. The following are increasingly maybe's */
/* although they are so easy to add that I see no reason not to.     */
(3) Endian-ness can either be determined at compile time ( by a #define )
    or perhaps better, can be a one-time low-level 'C' test that sets
    a symbol. ( look at (int) 1 as a char[2] )
(4) The sizes of native ints, longs, etc. may be useful for things like
    pack/unpack etc. It is certainly easy to figure out at compile-time.
    (  size.int = sizeof(int) ; size.long = sizeof(long) ... )
(5) Vaxen might need a value to indicate what type of floating point
    number support is compiled into python.


I propose that a dictionary object { 'cpu':'80x86', 'system':'posix', ... }
be either added to the sys module ( sys.arch, sys.machine, ? ) or that
a new "builtin" module be added ( machine ? ) that (initially) defines
some of these. ( We can then prototype suggested additions by importing
an additional module ( moresys.py ? ) that adds more mappings to the
dictionary. ( And perhaps module sys should "automagically" try to
do the equivalend of "import moresys" ? )

-------

Below is a module that determines what system it is by successful import.
If it is posix, it tries 'uname' or 'arch'  to get a more specific answer.
For mac & dos, it assumes the obvious for cpu.
[ Note: there is not YET a "dosmodule" to be imported. ]

I will probably change the names of things, so this is not a suggested
"standard" method.
[ Who was it that said: programming is largely the art of naming things well ?
  And the proper use of namespace is really the question, if we are talking
  about defining conventions. ( I admit this is not "well-named" - just a
  prototype|exercise that suggested some of the above issues. ) ]



# module os
#
#   os.module = appropriate os specific module
#                 i.e. posix , or its closest functional equivalent.
#          ( mac, dos ) - there is SOME common functionality
#          between them. ( listdir(), etc. )
#   os.isposix = 0 | 1 ( if import posix was successful )
#   os.system = { 'cpu':cpu-type, os:( os-tuple ), ... }
#
#  thus:
#    import os
#    def ls( ):
#    for file in os.module.listdir(''): print file
#
#  SHOULD work on any system.
#  ( If we add a directory-specifier argument to the above, we either
#    need to require that the user and any-other calling routines
#    use the proper local pathname format, or we need a posix-to-local
#    pathname converter function. )
#

import string

#
# Order of tests is because I was writing/testing on SunOS,
# and I wanted to make sure that the other paths were tried.
#
def _sysmodule():
   system = None
   try:
     import mac
     system = mac
   except ImportError:
     try:
       import dos
       system = dos
     except ImportError:
       try:
         import posix
         system = posix
   return system

module = _sysmodule()


#
# Note: this version makes several calls to uname ( if posix ) with
# switches ( -m(achine) -s(ystem) -r(release) ) to get specific info.
# I didn't know whether I could rely on a posix defined order with
# the -a(ll) switch.
#   SparcStation 'uname -a' returned:    "SunOS aemsun.me 4.1.1 1 sun4c"
#   IBM RS6000 'uname -a' returned:     "AIX galen 1 3 000019501100"
# I don't know how useful cpu = "000019501100" is !
# Also SunOS and AIX seem to differ on the meaning of the terms
#   'version' and 'release'. AIX appears to do it correctly, returning
#  "3" for 'uname -v', SunOS returns '1' .  I was writing/testing this
#  on a SUN, so I use 'uname -r' to get " 4.1.1"
# ( This was probably the source of my doubts about the posix order. )
#

def _cpu():
  if `module` == '<module \'dos\'>' : return 'i8x86'
  if `module` == '<module \'mac\'>' : return 'm68x00'
  if `module` == '<module \'posix\'>' :
     for cmd in [ 'uname -m', 'mach', 'arch' ]:   # add any other likely cmds!
    mach = module.popen( cmd, 'r' ).readline()
        if mach != '' : return string.strip( mach )
  return None


def _sys_generic():
    name = string.splitfields( `module`, '\'' )[1]
    return name

_true = 1
_false = 0

if _sys_generic() == 'posix' :
   isposix = _true
else:
   isposix = _false

if _sys_generic() == 'mac' :
   ismac = _true
else:
   ismac = _false

if _sys_generic() == 'dos' :
   isdos = _true
else:
   isdos = _false


def _system( ):
  generic = _sys_generic()
  if generic == 'posix' :
      sys = module.popen( 'uname -s','r').readline()    # system
      ver = module.popen( 'uname -r','r').readline()    # release
      return ( generic, string.strip(sys), string.strip(ver) )
  else: return ( generic, )  # may want to add more specific code, e.g.
                 # ( 'ms-dos', '5.01' ), ( 'mac','7.0.1'), etc.



system = { 'cpu':_cpu(), 'os':_system()   }

def check():
  print 'module: ', `module`
  print 'system',`system`,':'
  for each in system.keys() :
    print (' '*4)+string.ljust(each,9), ': ', system[each]
  import os    # interesting need to import own module!
          # else: dir() => 'each' & dir(os) => error
  for each in dir(os):
        thing = eval('os.'+each)
    print string.ljust(each,12), string.ljust(`type(thing)`,20), thing


check()

#
# needed:
#  machine support:
#   byte_order
#   sizes of native int,long
#   ieee, vax, or other floating-point
#   ... (?)
#  os-support:
#    ???
#  'portable' import:
#     if os.isdos :
#    import dospath
#    path = dospath
#     if os.ismac :
#    import macpath
#    path = macpath
#     if os.isposix :
#    import posixpath
#    path = posixpath
#    etc...
#   Note: if the above is in module 'path', then importing path
#   will make the function names 'path.path.function()' instead
#   of 'path.function'. Probably: "from path import path" will work.
#

I'll try to cobble out a prototype of a C include file for a
prototype sys.arch when I have more time. Any other suggestions
on what should be included/excluded ? I thing sys.arch could be
an dictionary object like 'system' above.

Note:
   I hate having to use literals for this sort of thing:
     if `module` == '<module \'dos\'>' : return 'i8x86'
     if `module` == '<module \'mac\'>' : return 'm68x00'
     if `module` == '<module \'posix\'>' :
  It is too error prone: especially when there are escapes, as above,
  it is easy to mispell and hard to check by any way other that
  actually executing the code. This was my same complaint previously
  about exceptions. ( I know Guido agrees that the exception namespace
  needs to be finer grained - I saw it on his "to-do" list! ). If one
  wants to check on a more specific error by the additional argument,
  one has to actually cause the exception to find out what the exact
  message is! type(''),type([]),etc. work ok as a replacement for
  type literals ( type( open('/dev/null','r' )  ) is not as neat, but
  I haven't been forced to use it yet! :-). But I have no better
  general solution to recommend.



Another Note:

* In ICON: *

procedure main( args )
  local n
  local c
  c :=  &digits ++ &lcase ++ &ucase

  write( "Hello World!  ", &dateline )
  write( "This is " ,  &version )
  write( "&Features include:" )
  every write( "    <*" , &features, "*>" )

  ...

  }
end


*** produces: ***

Hello World!  Tuesday, February 4, 1992  12:06 pm
This is Icon Version 8.0.  May 7, 1990
&Features include:
    <*UNIX*>
    <*ASCII*>
    <*co-expressions*>
    <*direct execution*>
    <*environment variables*>
    <*error trace back*>
    <*executable images*>
    <*expandable regions*>
    <*external functions*>
    <*large integers*>
    <*math functions*>
    <*memory monitoring*>
    <*pipes*>
    <*string invocation*>
    <*system function*>


I think this is overkill. ( for python, at least. ) This was due,
I imagine, to the Icon project wanting to provide *an* implementation,
even if limited, on many platforms. I would not expect the same sort
of functional differences in python on different platforms. Here the
problem is NOT whether or not there *are*, for example, pipes, but
how to make programs that use posix.listdir use mac.listdir with a
minimum of effort or source convention. [ Initially, I was going to
use posix.popen & msdos.popen as an example, but I agree with the
argument in comp.lang.icon that they are *not* semantically equal.
BUT close enough for the equivalence to be useful. ]


I also note that there has been some discussion in comp.lang.tcl
about handling UNIX-ism's on Mac-tcl and the converse. Mostly on
the subject of path-name-translation ( automatic or not, etc. )
I have no opinion (yet) on the matter.

Wishing-I-had-something-clever-to-say-here-like-tim-ingly yours,
( But the above has exhausted me! As Tim once said to me:
  "If I had more time, I would have made it shorter!" )

 - Steve

But to condense & reiterate the major point of the above discussion:
( That's easier than editing & rewriting the whole thing to make it
 clearer. :-& <grrr> )

Using the success/failure of modules posix|mac|dos|{whatever} to
determine what machine & system the program is executing on
( which is needed to do un-portable things portably ) is not
a good idea because it will conflict with 'aliasing' the modules
to provide portability. ( for example: making a posix.py module
for mac that attempts to provide some posix compatible emulation. )












Received: by charon.cwi.nl with SMTP; Wed, 5 Feb 1992 00:14:20 +0100
Received: by voorn.cwi.nl with SMTP; Tue, 4 Feb 1992 23:14:19 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Python portability planning ( and prototypes )
In-Reply-To: Your message of "Tue, 04 Feb 1992 15:56:25 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Wed, 05 Feb 1992 00:14:18 +0100
Sender: [e-mail]

Steve makes some good points again!  I'll think about it more in
three weeks, when I foresee I'll have some spare time again; for now
I'll just respond to his "management summary" at the end.

>Using the success/failure of modules posix|mac|dos|{whatever} to
>determine what machine & system the program is executing on
>( which is needed to do un-portable things portably ) is not
>a good idea because it will conflict with 'aliasing' the modules
>to provide portability. ( for example: making a posix.py module
>for mac that attempts to provide some posix compatible emulation. )

This depends on what you want to do.  If the attempt at posix
compatible emulation is good enough it doesn't matter whether
os.system == 'posix' or not, as long as I can say posix.stat(filename).

I don't see much use for knowing the CPU type, byte order, word size
and floating point format unless pack/unpack get implemented.  Come
on, most C code doesn't know or care about these (surely 99% of my own
code doesn't make any assumptions beyond what ANSI C guarantees), so
why should Python programs care?

There's one problem, however, which I can't completely "abstract
away": filename syntax.  I've attempted to isolate all knowledge about
pathnames in module path (or macpath on the Mac) but this is
incomplete, e.g., the released version has no predicate to test for
absobute pathnames, path.split() leaves a trailing '/' on the
directory name, there should be functions to normalize pathnames in
several ways (e.g., unify case, remove ignored characters, truncate
long names, remove "../", and expand ~ and ~user).  I am slowly adding
such functionality as the need arises, but I can't predict what
problem shows up on the next system I port it to (VMS comes to mind as
a good test case :-).

I admit that I've never really sat down and thought about an interface
to do every conceivable operation on pathnames.  Maybe there aren't
that many that are actually used, and we can come up with an interface
that will survive into the next century -- I don't know.

I do feel that with something like module path, Python has an
advantage over Tcl: there the Mac port was obviously an afterthought,
and apparently UNIX pathnames are used throughout Tcl's implementation
or in its standard library interfaces in a way that they aren't in
Python -- or why else would they even consider doing automatic
translation to Mac pathnames?  (OK, I didn't follow that discussion.)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Time is an illusion.  System time doubly so."











Received: by charon.cwi.nl with SMTP; Wed, 5 Feb 1992 11:02:22 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA18778; Wed, 5 Feb 92 05:02:17 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 050157.4264; Wed, 5 Feb 1992 05:01:57 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA04410; Wed, 5 Feb 92 04:48:41 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA14161; Wed, 5 Feb 92 04:48:39 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: More Emacs Python mode:  support for continuation lines
Date: Wed, 05 Feb 92 04:48:38 EST
From: Tim Peters <[e-mail]>

The default pattern is like:

if a_really_long_name == an_extraordinarily_long_name and \
      x < y < z < a < b < c < d < e < f < g < h < i and \
      not len(sys.argv) == 3:
    do_some_stuff()
    etc()

Change vrbl py-continuation-offset in your .emacs to something you like
better (it defaults to 2; it's added to py-indent-offset to determine
the indentation of the 1st continuation line).

Be warned that there *isn't* a single value you'll like in all
circumstances.  E.g., looking at the lib/*.py code, some multi-line
statements of Guido's used (in effect) a value of 8 for
py-continuation-offset, others 0, others 1, and there was even a -7 or
two (among others ...).  It depends on what you're doing & on what looks
nice in context, things I won't pretend to be able to guess.

For that reason, you should view the indentation Python-mode supplies
for a continuation line as just a lazy (humble <grin>) default; change
it to something you like better, and the code will follow your lead
until the statement ends.

Whatever oddball indentation you use during a multi-line statement will
*not* affect the normal indentation of subsequent statements.  So, e.g.,

animal_list = [ 'horse',    \
        'dog',        \    user hand-fiddled the indent here
        'cat',        \    LFD automatically did it here
        'python', ]        and here
death = taxes            and LFD knew that 0 indent is proper here

not-smart-but-accommodating-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

ps:  won't have time to hack Emacs the rest of the week, else I would
     have held back on this.  Back to the shadows ...

;; Major mode for editing Python programs.
;; by: Michael A. Guravage and Guido van Rossum <[e-mail]>
;;
;; The following statements, placed in your .emacs file or site-init.el,
;; will cause this file to be autoloaded, and python-mode invoked, when
;; visiting .py files (assuming the file is in your load-path):
;;
;;    (autoload 'python-mode "python-mode" "" t)
;;    (setq auto-mode-alist
;;          (cons '("\\.py$" . python-mode) auto-mode-alist))

;; Change log:
;
; Sun Feb  2 02:08:47 1992  tim
; added support for user-defined indentation increment:
;     added python-indent variable
;    changed py-indent-line to indent python-indent columns
;    fixed small bug in py-indent-line (changed start of r.e.
;        from [^#] to [^#\n])
;    added py-delete-char function; bound to \177
;    changed mode blurb accordingly
;
; Sun Feb  2 21:48:59 1992  tim
; renamed 'python-indent' to 'py-indent-offset' for internal consistency
; replaced regexp in py-indent-line so it no longer indents after
;    lines like:
;    a = b   # ok: # found
;    a = ': #'
;
; Mon Feb  3 20:37:27 1992  tim
; renamed file to 'python-mode.el' for consistency with other Emacs
;    language modes; changed autoload instructions accordingly
; improved accuracy of new/changed docs
; changed py-python-command from defconst to defvar so .emacs can
;    override it if desired
; add warning about indent-region; suggest indent-rigidly
;
; Wed Feb  5 03:23:31 1992  tim
; added support for auto-indenting of continuation lines:
;    new vrbl py-continuation-offset
;    new function py-continuation-line-p
;    new function py-goto-initial-line
;    new function py-compute-indentation
;    rewrote py-indent-line
; changed py-indent-line to refrain from modifying the buffer if the
;    indentation is already correct
; hid the hairy colon-line regexp in a const
; changed indent-region example to use legal Python
; documented all that

(provide 'python)

;; Constants and variables

(defvar py-python-command "python"
  "*UNIX shell command used to start Python interpreter")

(defvar py-indent-offset 4
  "*Indentation increment in Python mode")

(defvar py-continuation-offset 2
  "*Indentation (in addition to py-indent-offset) for continued lines")

(defvar py-mode-map nil
  "Keymap used in Python mode buffers")

(defvar py-mode-syntax-table nil
  "Python mode syntax table")

(defconst py-colon-line-re
  "\\([^#'\n]\\|'\\([^'\n\\]\\|\\\\.\\)*'\\)*:[ \t]*\\(#.*\\)?$"
  "regexp matching lines opening a new block")


;; Initialize the keymap if it doesn't already exist

(if (null py-mode-map)
    (progn
      (setq py-mode-map (make-sparse-keymap))
      (define-key py-mode-map "\C-c\C-c" 'py-execute-buffer)
      (define-key py-mode-map "\C-c|"     'py-execute-region)
      (define-key py-mode-map "\C-c!"     'py-shell)
      (define-key py-mode-map "\177"     'py-delete-char)))

;; General Functions

(defun python-mode nil
  "Major mode for editing Python files.

\\[py-execute-buffer] sends the entire buffer to the Python interpreter.
\\[py-execute-region] sends the current region.
\\[py-shell] starts a Python interpreter window; this will be used by
subsequent \\[py-execute-buffer] or \\[py-execute-region] commands.


Variable py-indent-offset is the indentation increment.

\\[newline-and-indent] indents by an extra py-indent-offset columns where
necessary.  Use \\[py-delete-char] to reduce indentation.

\\[py-delete-char] reduces the indentation of a line by py-indent-offset columns
if point is at the first non-blank character (if any) of a line, or at
the last character of an entirely blank line; else it deletes the
preceding character, converting tabs to spaces as needed so that only
one character position is deleted.

Variable py-continuation-offset is the additional indentation given to
the first continuation line in a multi-line statement.  Each subsequent
continuation line in the statement inherits its indentation from the
line that precedes it, so if you don't like the default indentation
given to the first continuation line, change it to something you do like
and Python-mode will automatically use that for the remaining
continuation lines (or, until you change the indentation again).

Warning:  indent-region should not be used!  Use indent-rigidly to shift
regions of Python code instead.  indent-region can't guess the
indentation you had in mind, and will, e.g., change

    xxx
    if a < b:
        c = d
    if e < f: print 'ouch!'

to
    xxx
    if a < b:
        c = d
        if e < f: print 'ouch!'

Paragraphs are separated by blank lines only.
\\{py-mode-map}
\\[python-mode] calls the value of the variable py-mode-hook with no args,
if that value is non-nil."
  (interactive)
  (kill-all-local-variables)
  (use-local-map py-mode-map)
  (setq major-mode 'python-mode)
  (setq mode-name "Python")
  (if py-mode-syntax-table
      (set-syntax-table py-mode-syntax-table)
    (progn
      (setq py-mode-syntax-table (make-syntax-table))
      (set-syntax-table py-mode-syntax-table)
      (modify-syntax-entry ?\( "()")
      (modify-syntax-entry ?\) ")(")
      (modify-syntax-entry ?\[ "(]")
      (modify-syntax-entry ?\] ")[")
      (modify-syntax-entry ?\{ "(}")
      (modify-syntax-entry ?\} "){")
      (modify-syntax-entry ?\_ "w")
      (modify-syntax-entry ?\' "\"")    ; single quote is string quote
      (modify-syntax-entry ?\` "$")    ; backquote is open and close paren
      (modify-syntax-entry ?\# "<")    ; hash starts comment
      (modify-syntax-entry ?\n ">")    ; newline ends comment
      ))
  (make-local-variable 'paragraph-separate)
  (setq paragraph-separate "^[ \t\f]*$")
  (make-local-variable 'paragraph-start)
  (setq paragraph-start "^[ \t\f]*$")
  (make-local-variable 'require-final-newline)
  (setq require-final-newline t)
  (make-local-variable 'comment-start)
  (setq comment-start "# ")
  (make-local-variable 'comment-start-skip)
  (setq comment-start-skip "# *")
  (make-local-variable 'comment-column)
  (setq comment-column 40)
  (make-local-variable 'indent-line-function)
  (setq indent-line-function 'py-indent-line)
  (run-hooks 'py-mode-hook))


;; Functions that execute Python commands in a subprocess

(defun py-shell nil
  "Start an interactive Python interpreter in another window.
The variable py-python-command names the interpreter."
  (interactive)
  (require 'shell)
  (switch-to-buffer-other-window
   (make-shell "Python" py-python-command))
  (make-local-variable 'shell-prompt-pattern)
  (setq shell-prompt-pattern "^>>> \\|^\\.\\.\\. "))

(defun py-execute-region (start end)
  "Send the region between START and END to a Python interpreter.
If there is a *Python* process it is used."
  (interactive "r")
  (condition-case nil
      (process-send-string "Python" (buffer-substring start end))
    (error (shell-command-on-region start end py-python-command nil))))

(defun py-execute-buffer nil
  "Send the contents of the buffer to a Python interpreter.
If there is a *Python* process buffer it is used."
  (interactive)
  (py-execute-region (point-min) (point-max)))


;; Functions for Python style indentation

(defun py-delete-char ()
  "If at first non-blank character, or at last character of blank line,
reduce indentation by the value of variable py-indent-offset.  Else
delete preceding character, converting tabs to spaces."
  (interactive)
  (backward-delete-char-untabify
   (if (and
    (= (current-indentation) (current-column))
    (>= (current-indentation) py-indent-offset))
       py-indent-offset
     1)))

(defun py-indent-line ()
  "Fix the indentation of the current line according to Python rules."
  (interactive)
  (let ( (need (py-compute-indentation)) )
    (if (= (current-indentation) need)
    nil
      (beginning-of-line)
      (delete-horizontal-space)
      (indent-to need))))

; go to start of current statement; usually this is the line we're on,
; but if we're on the 2nd or following lines of a continuation block, we
; need to go up to the first line of the block
(defun py-goto-initial-line ()
  (if (re-search-backward "[^\\]\n" (point-min) 1)
      (forward-char 2))) ; else leave point at start of restriction

; t iff on continuation line == preceding line ends with backslash
(defun py-continuation-line-p ()
  (save-excursion
    (beginning-of-line)
    (if (< (- (point) 2) (point-min))
    nil
      (backward-char 2)
      (looking-at "\\\\\n"))))

(defun py-compute-indentation ()
  (save-excursion
    (beginning-of-line)
    (cond
     ;; are we on a continuation line?
     ( (py-continuation-line-p)
       (forward-line -1)
       (if (py-continuation-line-p) ; on at least 3rd line in block
       (current-indentation)    ; so just continue the pattern
     ;; else on 2nd line in block, so indent more
     (+ (current-indentation) py-indent-offset
        py-continuation-offset)))
     ;; not on a continuation line

     ;; if at start of restriction, assume they intended whatever's there
     ( (bobp) (current-indentation) )

     ;; else indentation based on that of the statement that precedes
     ;; us; use the first line of that statement to establish the base,
     ;; in case the user forced a non-std indentation for the
     ;; continuation lines (if any)
     ( t
       (backward-to-indentation 1)
       (let ( (need-more-p (looking-at py-colon-line-re)) )
     (py-goto-initial-line)
     (if need-more-p
         (+ (current-indentation) py-indent-offset)
       (current-indentation)))))))

;; To do:
;; - add a newline when executing buffer ending in partial line
;; - suppress prompts when executing regions
;; - switch back to previous buffer when starting shell
;; - support for ptags

>>> END OF MSG










Replied: Thu, 06 Feb 1992 11:47:35 +0100
Replied: "[e-mail] "
Received: by charon.cwi.nl with SMTP; Wed, 5 Feb 1992 21:25:06 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa14921;
          5 Feb 92 15:24 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA07952; Wed, 5 Feb 92 15:15:08 EST
Date: Wed, 5 Feb 92 15:15:08 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Python portability planning ( and prototypes )
Cc: [e-mail]


me> Using the success/failure of modules posix|mac|dos|{whatever} to
me> determine what machine & system the program is executing on
me> ( which is needed to do un-portable things portably ) is not
me> a good idea because it will conflict with 'aliasing' the modules
me> to provide portability. ( for example: making a posix.py module
me> for mac that attempts to provide some posix compatible emulation. )

guido> This depends on what you want to do.  If the attempt at posix
guido> compatible emulation is good enough it doesn't matter whether
guido> os.system == 'posix' or not, as long as I can say posix.stat(filename).


Agreed!
But what I'm aiming for is that source code libraries be portable
*without* renaming or editing files. [ It is not a big bother right
now, but it will grow as the libraries grow. I'm trying to nip library
management in the bud.] So if there IS posix emulation, then either
POSIXposix, macposix, or dosposix will be loaded. ( Not exactly accurate,
I know posix & mac are "built-in", but you get the idea. ).

True: it is not a *frequently* needed feature. It will (probably) only
be used (occasionally) when module are imported.


guido> I don't see much use for knowing the CPU type, byte order, word size
guido> and floating point format unless pack/unpack get implemented.  Come
guido> on, most C code doesn't know or care about these (surely 99% of my own
guido> code doesn't make any assumptions beyond what ANSI C guarantees), so
guido> why should Python programs care?

You got it backward: If there is a low level implementation of pack/unpack,
then we *DON'T* need to know byte-order or work size. If pack/unpack and
other network & native binary conversions are done in python-source, THEN
we DO need byte-order and word size. [ I don't really care about CPU type -
that was only because posix uname ( or arch ) seemed to be the only
(indirect) way of inferring the byte-order & (possibly) work size. ]

Again, I admit: Infrequently needed. But essential for a whole class of
problems. C network programs use htons(), etc. to convert to/from native
and network byte orders. C programs are FULL of "sizeof()"'s [ The need
for which disappears in Python 98+% of the time, but again, that 1 or 2%
either shuts out a whole class of problems or it forces some one to dig
into internals ( either of Python or the machine ) to find out the answer
and HARD-WIRE it into their program - the extreme of non-portability! ]

I think the minimum necessary functionality and the most portable
way of providing it is still an open question. [ And it is the question
I was trying to raise in the original pack/unpack discussion. ]


I may be more concerned about these things than some other folks:
I'm currently trying to move 10 YEARS and HUNDREDS of TAPES worth
of non portable vax vms record structured files some with VAX ( non IEEE )
floating point data into a portable network-neutral (i.e. readable by any
machine without any intermediate conversion program) format, so I may
be a bit more obsessed about this than the average programmer.
[ Plus all of the data from PC's & Mac's that get ftp-ed to and from
 Sparc's, Vaxen & RS6000's et.al. ]

The ideal is to make both program and data portable. But we're not there
yet, so the next best thing is to provide a "portable" was to handle
non-portable objects. [ ntohs(),htons(),etc. is an example:
network-byte-order-16-bit-to-host-byte-order-short ( and vice versa )
For some machines that function is a no-op. But all portable network
programs that use binary data NEED that function to BE portable. ]

[ I think that aesthetically, Guido, you want things to be *SO*
  portable that you DON'T NEED to know WHAT machine you are running on,
  ( or what byte-order is native, etc. ) but I'm argueing that the only
  way to MAKE some things have a portable interface is for some level
  to know that information, and modify it's actions accordingly. ]

You might reply that binary file conversion is not a proper job for Python.
If I want to get down and twiddle bits, I should be using C!
However one of the typical uses of Awk/Perl/et.al. ( and I would think
Icon & Python both ) is to read files in one format and spit them out
in another format. Usually these are ascii character files, but the
problems with binary files are not very different.


[ BTW: A different but related problem is a "portable" 'file' program.
  Someone was working on a Perl solution a while back. 'file' itself
  is limited: it matches fixed fields and there is a double byte order
  problem - the byte order of the file and the byte order of the
  machine that 'file' is running on, that made it impossible to
  make a portable version of /etc/magic' that could be shared by
  different machines. The best solution I saw ( other that the perl
  re-write of file ) was a version of /etc/magic that was run through
  the C pre-processor to make local variants. But any one local copy
  was not sharable. Before I ran into all these problems, I was
  considering a crusade to convince developers of archiver,compression,
  graphics,etc. programs to provide a "magic" file and make their
  installation scripts (if any) append their "magic" to "/etc/magic".
  I nice idea that turns out not to be as simple as it sounds. ]


[ various interesting comments by Guido on portable pathnames deleted ... ]

That is also something I'm only STARTING to think about!
It is a similar problem. How to make the different path name syntax
and conventions appear portable, without making some native files
un-nameable and un-reachable.
*IF* we need a routine to convert to/from a cannonical ( probably
posix style ) pathname to/from a local style pathname ( I'm not sure
that we do, but I think so, unless everyone remembers to only use
the least common denominator path names, or unless that conversion
is built into the builtin module's "open" . ) then that module has to
have some local information!

( I haven't even read all the threads in comp.lang.{tcl,perl} about
    handling unix-ism's - only noted that there was a discussion.
  Maybe we need a comp.port  !!! [ for cross language/systems
  discussions of portable ( from the user  syntax/interface ) ways
  to handle non-portable features. ] )


- Steve










Received: by charon.cwi.nl with SMTP; Thu, 6 Feb 1992 07:02:10 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA17875; Thu, 6 Feb 92 01:02:06 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 010154.15162; Thu, 6 Feb 1992 01:01:54 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA17660; Thu, 6 Feb 92 00:42:33 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA23396; Thu, 6 Feb 92 00:42:32 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Will these Python Emacs modes never stop?!
Date: Thu, 06 Feb 92 00:42:30 EST
From: Tim Peters <[e-mail]>

Couldn't help myself <0.9 grin>.

Three new keys:

C-c TAB
C-c <
C-c >

These all have to do with shifting a region of Python code.  C-c TAB is
the most important one, and indeed can do anything the other two can do
(although the other two may be more convenient at times).

Example:  Say you're typing away in file a.py:

    this = that

and need some code to get a temp file name.  You remember you have some
in file b.py, so you visit that, cut it out, go back to a.py, and yank
it in (C-y) after the line above.  This leaves you with:

    this = that
if tmpfilename == '':
    for i in range(100):
    tmpfilename = '/tmp/tmp' + `posix.getpid()` + '.' + `i`
    if not path.exists(tmpfilename): break
    else: raise TmpError, 'all /tmp names already taken'

and an indentation headache.  No more!  Just hit C-c TAB to get:

    this = that
    if tmpfilename == '':
        for i in range(100):
        tmpfilename = '/tmp/tmp' + `posix.getpid()` + '.' + `i`
        if not path.exists(tmpfilename): break
        else: raise TmpError, 'all /tmp names already taken'

In other words, C-c TAB shifts regions of Python code, by an amount
based on context, much as TAB does for individual lines.

You can also give an absolute shift count to C-c TAB.  C-c < and C-c >
just shift a region of code left or right (respectively) by py-indent-
offset columns (or by any other amount you like, if you give them a
numeric prefix argument).

getting-close-to-having-a-real-language-mode<grin>-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

;; Major mode for editing Python programs.
;; by: Michael A. Guravage and Guido van Rossum <[e-mail]>
;;
;; The following statements, placed in your .emacs file or site-init.el,
;; will cause this file to be autoloaded, and python-mode invoked, when
;; visiting .py files (assuming the file is in your load-path):
;;
;;    (autoload 'python-mode "python-mode" "" t)
;;    (setq auto-mode-alist
;;          (cons '("\\.py$" . python-mode) auto-mode-alist))

;; Change log:
;
; Sun Feb  2 02:08:47 1992  tim
; added support for user-defined indentation increment:
;     added python-indent variable
;    changed py-indent-line to indent python-indent columns
;    fixed small bug in py-indent-line (changed start of r.e.
;        from [^#] to [^#\n])
;    added py-delete-char function; bound to \177
;    changed mode blurb accordingly
;
; Sun Feb  2 21:48:59 1992  tim
; renamed 'python-indent' to 'py-indent-offset' for internal consistency
; replaced regexp in py-indent-line so it no longer indents after
;    lines like:
;    a = b   # ok: # found
;    a = ': #'
;
; Mon Feb  3 20:37:27 1992  tim
; renamed file to 'python-mode.el' for consistency with other Emacs
;    language modes; changed autoload instructions accordingly
; improved accuracy of new/changed docs
; changed py-python-command from defconst to defvar so .emacs can
;    override it if desired
; add warning about indent-region; suggest indent-rigidly
;
; Wed Feb  5 03:23:31 1992  tim
; added support for auto-indenting of continuation lines:
;    new vrbl py-continuation-offset
;    new function py-continuation-line-p
;    new function py-goto-initial-line
;    new function py-compute-indentation
;    rewrote py-indent-line
; changed py-indent-line to refrain from modifying the buffer if the
;    indentation is already correct
; hid the hairy colon-line regexp in a const
; changed indent-region example to use legal Python
; documented all that
;
; Wed Feb  5 21:52:15 1992  tim
; changed new doc strings so first line makes sense on its own
; new function py-shift-region; bound to C-c TAB
; new function py-shift-region-left; bound to C-c <
; new function py-shift-region-right; bound to C-c >
; reorganized mode blurb
; sped up py-continuation-line-p

(provide 'python)

;; Constants and variables

(defvar py-python-command "python"
  "*UNIX shell command used to start Python interpreter")

(defvar py-indent-offset 4
  "*Indentation increment in Python mode")

(defvar py-continuation-offset 2
  "*Indentation (in addition to py-indent-offset) for continued lines")

(defvar py-mode-map nil
  "Keymap used in Python mode buffers")

(defvar py-mode-syntax-table nil
  "Python mode syntax table")

(defconst py-colon-line-re
  "\\([^#'\n]\\|'\\([^'\n\\]\\|\\\\.\\)*'\\)*:[ \t]*\\(#.*\\)?$"
  "regexp matching lines opening a new block")


;; Initialize the keymap if it doesn't already exist

(if (null py-mode-map)
    (progn
      (setq py-mode-map (make-sparse-keymap))
      (define-key py-mode-map "\C-c\C-c" 'py-execute-buffer)
      (define-key py-mode-map "\C-c|"     'py-execute-region)
      (define-key py-mode-map "\C-c!"     'py-shell)
      (define-key py-mode-map "\177"     'py-delete-char)
      (define-key py-mode-map "\C-c\C-i" 'py-shift-region)
      (define-key py-mode-map "\C-c<"     'py-shift-region-left)
      (define-key py-mode-map "\C-c>"     'py-shift-region-right)))

;; General Functions

(defun python-mode nil
  "Major mode for editing Python files.

Paragraphs are separated by blank lines only.

\\[python-mode] calls the value of the variable py-mode-hook with no args,
if that value is non-nil.

INTERFACE TO PYTHON INTERPRETER

\\[py-execute-buffer]    sends the entire buffer to the Python interpreter
\\[py-execute-region]    sends the current region.
\\[py-shell]    starts a Python interpreter window; this will be used by
    subsequent \\[py-execute-buffer] or \\[py-execute-region] commands

VARIABLES

py-indent-offset    indentation increment
py-continuation-offset    extra indentation given to continuation lines

INDENTATION

\\[newline-and-indent]    indent line appropriately
\\[py-delete-char]    reduce indentation, or delete single character
\\[py-shift-region-left]    shift region left by py-indent-offset
\\[py-shift-region-right]    shift region right by py-indent-offset
\\[py-shift-region]    shift region to match its context

\\[newline-and-indent] indents by an extra py-indent-offset columns where
necessary.

\\[py-delete-char] reduces the indentation of a line by py-indent-offset columns
if point is at the first non-blank character (if any) of a line, or at
the last character of an entirely blank line; else it deletes the
preceding character, converting tabs to spaces as needed so that only
one character position is deleted.

py-continuation-offset is the additional indentation given to the first
continuation line in a multi-line statement.  Each subsequent
continuation line in the statement inherits its indentation from the
line that precedes it, so if you don't like the default indentation
given to the first continuation line, change it to something you do like
and Python-mode will automatically use that for the remaining
continuation lines (or, until you change the indentation again).

\\[py-shift-region-left] shifts the region left by py-indent-offset columns.

\\[py-shift-region-right] shifts the region right by py-indent-offset columns.

\\[py-shift-region] shifts the region to indent it properly with respect
to the line preceding the region.  This is useful when code blocks are
moved or yanked, or when enclosing control structures are introduced or
removed.

The three \"shift\" functions above also honor numeric prefix arguments;
see the individual function documentation for details.

Warning:  indent-region should not normally be used!  It can't guess the
indentation you had in mind, and will, e.g., change

    xxx
    if a < b:
        c = d
    if e < f: print 'ouch!'

to
    xxx
    if a < b:
        c = d
        if e < f: print 'ouch!'

MODE MAP
\\{py-mode-map}"
  (interactive)
  (kill-all-local-variables)
  (use-local-map py-mode-map)
  (setq major-mode 'python-mode)
  (setq mode-name "Python")
  (if py-mode-syntax-table
      (set-syntax-table py-mode-syntax-table)
    (progn
      (setq py-mode-syntax-table (make-syntax-table))
      (set-syntax-table py-mode-syntax-table)
      (modify-syntax-entry ?\( "()")
      (modify-syntax-entry ?\) ")(")
      (modify-syntax-entry ?\[ "(]")
      (modify-syntax-entry ?\] ")[")
      (modify-syntax-entry ?\{ "(}")
      (modify-syntax-entry ?\} "){")
      (modify-syntax-entry ?\_ "w")
      (modify-syntax-entry ?\' "\"")    ; single quote is string quote
      (modify-syntax-entry ?\` "$")    ; backquote is open and close paren
      (modify-syntax-entry ?\# "<")    ; hash starts comment
      (modify-syntax-entry ?\n ">")    ; newline ends comment
      ))
  (make-local-variable 'paragraph-separate)
  (setq paragraph-separate "^[ \t\f]*$")
  (make-local-variable 'paragraph-start)
  (setq paragraph-start "^[ \t\f]*$")
  (make-local-variable 'require-final-newline)
  (setq require-final-newline t)
  (make-local-variable 'comment-start)
  (setq comment-start "# ")
  (make-local-variable 'comment-start-skip)
  (setq comment-start-skip "# *")
  (make-local-variable 'comment-column)
  (setq comment-column 40)
  (make-local-variable 'indent-line-function)
  (setq indent-line-function 'py-indent-line)
  (run-hooks 'py-mode-hook))


;; Functions that execute Python commands in a subprocess

(defun py-shell nil
  "Start an interactive Python interpreter in another window.
The variable py-python-command names the interpreter."
  (interactive)
  (require 'shell)
  (switch-to-buffer-other-window
   (make-shell "Python" py-python-command))
  (make-local-variable 'shell-prompt-pattern)
  (setq shell-prompt-pattern "^>>> \\|^\\.\\.\\. "))

(defun py-execute-region (start end)
  "Send the region between START and END to a Python interpreter.
If there is a *Python* process it is used."
  (interactive "r")
  (condition-case nil
      (process-send-string "Python" (buffer-substring start end))
    (error (shell-command-on-region start end py-python-command nil))))

(defun py-execute-buffer nil
  "Send the contents of the buffer to a Python interpreter.
If there is a *Python* process buffer it is used."
  (interactive)
  (py-execute-region (point-min) (point-max)))


;; Functions for Python style indentation

(defun py-delete-char ()
  "Reduce indentation or delete character.
If at first non-blank character, or at last character of blank line,
reduce indentation by the value of variable py-indent-offset.  Else
delete preceding character, converting tabs to spaces."
  (interactive)
  (backward-delete-char-untabify
   (if (and
    (= (current-indentation) (current-column))
    (>= (current-indentation) py-indent-offset))
       py-indent-offset
     1)))

(defun py-indent-line ()
  "Fix the indentation of the current line according to Python rules."
  (interactive)
  (let ( (need (py-compute-indentation)) )
    (if (= (current-indentation) need)
    nil
      (beginning-of-line)
      (delete-horizontal-space)
      (indent-to need))))

; go to start of current statement; usually this is the line we're on,
; but if we're on the 2nd or following lines of a continuation block, we
; need to go up to the first line of the block
(defun py-goto-initial-line ()
  (if (re-search-backward "[^\\]\n" (point-min) 1)
      (forward-char 2))) ; else leave point at start of restriction

; t iff on continuation line == preceding line ends with backslash
(defun py-continuation-line-p ()
  (save-excursion
    (beginning-of-line)
    (eq (char-after (- (point) 2)) ; nil if argument out of range
    ?\\ )))

(defun py-compute-indentation ()
  (save-excursion
    (beginning-of-line)
    (cond
     ;; are we on a continuation line?
     ( (py-continuation-line-p)
       (forward-line -1)
       (if (py-continuation-line-p) ; on at least 3rd line in block
       (current-indentation)    ; so just continue the pattern
     ;; else on 2nd line in block, so indent more
     (+ (current-indentation) py-indent-offset
        py-continuation-offset)))
     ;; not on a continuation line

     ;; if at start of restriction, assume they intended whatever's there
     ( (bobp) (current-indentation) )

     ;; else indentation based on that of the statement that precedes
     ;; us; use the first line of that statement to establish the base,
     ;; in case the user forced a non-std indentation for the
     ;; continuation lines (if any)
     ( t
       (backward-to-indentation 1)
       (let ( (need-more-p (looking-at py-colon-line-re)) )
     (py-goto-initial-line)
     (if need-more-p
         (+ (current-indentation) py-indent-offset)
       (current-indentation)))))))

(defun py-shift-region (start end &optional count)
  "Shift region of Python code horizontally.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
shifted the same amount, so that they're indented properly with respect
to the line immediately preceding the region.  This is useful when code
blocks are moved or yanked, or when enclosing control structures are
introduced or removed.
If a prefix argument is given, the region is instead shifted by that
many columns (to the right if the prefix argument is positive, else to
the left)."
  (interactive "*r\nP")   ; region; raw prefix arg
  (save-excursion
    (goto-char end)   (beginning-of-line) (setq end (point))
    (goto-char start) (beginning-of-line) (setq start (point))
    (indent-rigidly start end
            (if (null count)
            (- (py-compute-indentation)
               (current-indentation))
              (prefix-numeric-value count)))))

(defun py-shift-region-left (start end &optional count)
  "Shift region of Python code to the left.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
shifted to the left, by py-indent-offset columns.

If a prefix argument is given, the region is instead shifted by that
many columns."
  (interactive "*r\nP")   ; region; raw prefix arg
  (py-shift-region start end
           (- (if (null count)
              py-indent-offset
            (prefix-numeric-value count)))))

(defun py-shift-region-right (start end &optional count)
  "Shift region of Python code to the right.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
shifted to the right, by py-indent-offset columns.

If a prefix argument is given, the region is instead shifted by that
many columns."
  (interactive "*r\nP")   ; region; raw prefix arg
  (py-shift-region start end (or count py-indent-offset)))

;; To do:
;; - add a newline when executing buffer ending in partial line
;; - suppress prompts when executing regions
;; - switch back to previous buffer when starting shell
;; - support for ptags

>>> END OF MSG










Received: by charon.cwi.nl with SMTP; Thu, 6 Feb 1992 11:47:39 +0100
Received: by voorn.cwi.nl with SMTP; Thu, 6 Feb 1992 10:47:37 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Python portability planning ( and prototypes )
In-Reply-To: Your message of "Wed, 05 Feb 1992 15:15:08 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 06 Feb 1992 11:47:36 +0100
Sender: [e-mail]

>But what I'm aiming for is that source code libraries be portable
                                 ^^^^^^^^^^^^^^^^^^^^^
>*without* renaming or editing files.

Good point!  (I assume you mean what I call the "standard library
modules".)

>[ It is not a big bother right
>now, but it will grow as the libraries grow. I'm trying to nip library
>management in the bud.] So if there IS posix emulation, then either
>POSIXposix, macposix, or dosposix will be loaded. ( Not exactly accurate,
>I know posix & mac are "built-in", but you get the idea. ).

Excellent idea, this is a very nice solution.  As an extension, the
built-in posix emulations could export themselves under two names:
'posix' for naive programs, and '<OSNAME>posix' for programs that want
to know.  (I suggest using 'unix' for <OSNAME> in the UNIX case.)

>guido> I don't see much use for knowing the CPU type, byte order, word size
>guido> and floating point format unless pack/unpack get implemented.  Come
>guido> on, most C code doesn't know or care about these (surely 99% of my own
>guido> code doesn't make any assumptions beyond what ANSI C guarantees), so
>guido> why should Python programs care?
>
>You got it backward: If there is a low level implementation of pack/unpack,
>then we *DON'T* need to know byte-order or work size. If pack/unpack and
>other network & native binary conversions are done in python-source, THEN
>we DO need byte-order and word size. [ I don't really care about CPU type -
>that was only because posix uname ( or arch ) seemed to be the only
>(indirect) way of inferring the byte-order & (possibly) work size. ]

I still don't agree.  You don't need the byte order and word size
of the current machine -- you need the byte order and word size of the
machine that created the binary file you are trying to read (or where
the binary file you are going to write will be used).  Since you say
you want to do this for conversion jobs, I expect these will often be
different from the current machine!

>Again, I admit: Infrequently needed. But essential for a whole class of
>problems. C network programs use htons(), etc. to convert to/from native
>and network byte orders. C programs are FULL of "sizeof()"'s [ The need
>for which disappears in Python 98+% of the time, but again, that 1 or 2%
>either shuts out a whole class of problems or it forces some one to dig
>into internals ( either of Python or the machine ) to find out the answer
>and HARD-WIRE it into their program - the extreme of non-portability! ]

It's extremely simple to add a command line option, environment
variable or more sophisticated configuration mechanism whereby byte
order and word size can be specified to such conversion programs.
Hard-wiring in the native parameters makes the program non-portable if
the conversion has to run on a different platform.  As an example, C++
to C translators usually read a little file specifying the size and
alignment of C data structures on the target machine.

I admit that it's probably useful to have the native parameters
available for defaults in many cases.  So they should be available,
and getting these from a built-in interface is more reliable than
using a configuration file.  The next version of the posix module will
already contain a uname() call, so it's also a possibility make a
portable library module that translates pairs of (osname, machinetype)
into byte order and int size.  (There's no rule in POSIX that says
that different OS's running on the same machine must return the same
string, so the osname must figure in the argument.)

>[ I think that aesthetically, Guido, you want things to be *SO*
>  portable that you DON'T NEED to know WHAT machine you are running on,
>  ( or what byte-order is native, etc. ) but I'm argueing that the only
>  way to MAKE some things have a portable interface is for some level
>  to know that information, and modify it's actions accordingly. ]

Agreed.  Is what I said above enough water it the wine?

>You might reply that binary file conversion is not a proper job for Python.
>If I want to get down and twiddle bits, I should be using C!

But I won't.  Python can do this, and if reading a binary file is a
small part of the conversion process, or if it's a one-time job,
Python is quite suitable (especially if you already know to program in
Python).

>*IF* we need a routine to convert to/from a cannonical ( probably
>posix style ) pathname to/from a local style pathname ( I'm not sure
>that we do, but I think so, unless everyone remembers to only use
>the least common denominator path names, or unless that conversion
>is built into the builtin module's "open" . ) then that module has to
>have some local information!

I am very much against adopting a standard Python style of pathnames
(i.e. saying that '/' is the pathname delimiter on all systems and
translating to the native delimiter on systems where it differs).
The arguments passed to open(), stat(), listdir() etc. and the return
values of getcwd(), readlink() etc. must definitely be pathnames in
the native system's syntax.  Since most pathnames will be typed by the
user (e.g. on the command line) or retrieved from the system somehow,
this can't be a big problem.  Where you hard-code pathnames in a
program they usually have to be edited when moving the program to a
different site anyway.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I could be arguing in my spare time."










Received: by charon.cwi.nl with SMTP; Thu, 6 Feb 1992 19:41:04 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa00770;
          6 Feb 92 13:40 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA09247; Thu, 6 Feb 92 13:31:15 EST
Date: Thu, 6 Feb 92 13:31:15 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Python portability planning ( and prototypes )
Cc: [e-mail]


>
> >guido> I don't see much use for knowing the CPU type, byte order, word size
> >guido> and floating point format unless pack/unpack get implemented.
> >
> >You got it backward: If there is a low level implementation of pack/unpack,
> >then we *DON'T* need to know byte-order or work size. If pack/unpack and
> >other network & native binary conversions are done in python-source, THEN
> >we DO need byte-order and word size. [ I don't really care about CPU type -
> >that was only because posix uname ( or arch ) seemed to be the only
> >(indirect) way of inferring the byte-order & (possibly) work size. ]
>
> I still don't agree.  You don't need the byte order and word size
> of the current machine -- you need the byte order and word size of the
> machine that created the binary file you are trying to read (or where
> the binary file you are going to write will be used).  Since you say
> you want to do this for conversion jobs, I expect these will often be
> different from the current machine!
>

Oops! Well, maybe what I meant was you need it *even more* if you need
to implement pack/unpack in python-source.


> It's extremely simple to add a command line option, environment
> variable or more sophisticated configuration mechanism whereby byte
> order and word size can be specified to such conversion programs.

If I may quote you from another context:
guido> I don't see much use for knowing the CPU type, byte order, word size
guido> and floating point format unless pack/unpack get implemented.  Come
guido> on, most C code doesn't know or care about these  ...

Oh ! So the *programmers* DON'T know what byte order they are using, but now
you expect the *USERS* to know! :-)

Actually, you have a point. I don't expect them to know what byte order
is, but it is reasonable for them to know that what they are trying to
do is convert IBM-PC files to Sparc/Unix files of some type. So I reject
the idea of an option like 'dd's "conv=swab", but something like
"-from pc" is reasonable. But I still want to keep the "low-level" code
portable.


Also, I WILL admit that *I* don't know the byte order of various machines
off the top of my head. But I *do* know that there is a "network byte
order" and conversions to/from that and native byte order. ( This, again,
is my paradigmatic example of "good portable non-portabilities" ).
And I sometimes remember that two particular machines are different
( even if I can't remember which one is big-endian or how they relate
to a third architecture. ). [ "Oh - this file came from a PC, so I'd
better 'swab' it!" - That's the paradigmatic "bad" example! ]



>
> >*IF* we need a routine to convert to/from a cannonical ( probably
> >posix style ) pathname to/from a local style pathname ( I'm not sure
> >that we do, but I think so, unless everyone remembers to only use
> >the least common denominator path names, or unless that conversion
> >is built into the builtin module's "open" . ) then that module has to
> >have some local information!
>
> I am very much against adopting a standard Python style of pathnames
> (i.e. saying that '/' is the pathname delimiter on all systems and
> translating to the native delimiter on systems where it differs).
> The arguments passed to open(), stat(), listdir() etc. and the return
> values of getcwd(), readlink() etc. must definitely be pathnames in
> the native system's syntax.  Since most pathnames will be typed by the
> user (e.g. on the command line) or retrieved from the system somehow,
> this can't be a big problem.  Where you hard-code pathnames in a
> program they usually have to be edited when moving the program to a
> different site anyway.
>

I agree. ( I think! :-)
"Native" names should be the norm for interactive usage.
Where pathname need to be written into a program, then it is not
unreasonable to expect the programmer to explicitly use a
"path.to_native" conversion function, to indicate that he doesn't
actually MIND if the pathname get's munged up ( truncated | character
translated | etc. ) as long as there is a determinate mapping.
( for practical purposes one-to-one )



I think we are in agreement on:
(1) There will be ( for example ) a 'path' module for unix|dos|mac|etc.
    that will attempt to hide or at least isolate machine differences.
(2) That portable code should only need to import 'path', and not
    need to figure out which 'specific' module ( unixpath|macpath|dospath )
    it needs to load. [ I don't care what mechanics we choose to do this,
    as long as we can hide the machinery! ]
(3) But searching for module dependencies and renameing files is not
    the preferred solution to the above. [ The machinery here is
    painfully visible, even if only visible to ONE person ( the site
    maintainer/installer of Python. ]

The binary read/write issue is a completely different question. The two
are only linked because of using successful import of a "built-in" module
to determine local information. [ Which is why it is a bad method. ]


Gotta go hear a man talk about Wavelet's!
Bye for now,
- Steve

[ BTW: I have managed to get my packet drivers working on my 486 PC,
  So I can telnet the python sources onto it. I have the Gnu C compiler
  PC port installed, So I hope to start porting Python *REAL SOON* ]










Received: by charon.cwi.nl with SMTP; Thu, 6 Feb 1992 23:21:34 +0100
Received: by voorn.cwi.nl with SMTP; Thu, 6 Feb 1992 22:21:33 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Python portability planning ( and prototypes )
In-Reply-To: Your message of "Thu, 06 Feb 1992 13:31:15 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 06 Feb 1992 23:21:32 +0100
Sender: [e-mail]

>Oh ! So the *programmers* DON'T know what byte order they are using, but now
>you expect the *USERS* to know! :-)

Actually, for most file formats I've encountered it's pretty easy for
the conversion program to infer the byte order used by a file from the
first few bytes of data (e.g. a magic number) -- presuming the
conversion program what the data is supposed to look like...

In general users needn't know what byte order a file is in -- the hard
part is knowing what the format is in the first place.  Maybe "magic
(a replacement for file(1) written in Perl just posted on the net) can
help them with that -- although for me it just said
``Undefined subroutine "main'BufMatch" called at magic.pl line 429.''

>Actually, you have a point. I don't expect them to know what byte order
>is, but it is reasonable for them to know that what they are trying to
>do is convert IBM-PC files to Sparc/Unix files of some type. So I reject
>the idea of an option like 'dd's "conv=swab", but something like
>"-from pc" is reasonable. But I still want to keep the "low-level" code
>portable.

Given some table mapping architectures to byte orders you could add a
"-to sparc" option.  But of course the "dd" example is naive: no file
formats consists of arrays of words that can be byte-swapped like
that; in reality you will have to write code that understands the data
and knows when to swap words or longs or nothing.

>Also, I WILL admit that *I* don't know the byte order of various machines
>off the top of my head. But I *do* know that there is a "network byte
>order" and conversions to/from that and native byte order.

Reading a word in network byte order is easy in Python:

    def rwordn(fp):
        s = fp.read(2)
        if len(s) < 2: raise EOFError
        hibyte, lobyte = ord(s[0]), ord(s[1])
        return hibyte<<8 | lobyte

Writing is of course as easy.  There's no need to know the byte order
used by Python here.  This assumes network byte order is big-endian
(hibyte first), which is what the Internet specifies -- but who knows
what other networks use?

You can write similar routines rwordb() and rwordl() to read words in
big and little endian order -- rwordb() will of course be identical to
rwordn().

>Where pathname need to be written into a program, then it is not
>unreasonable to expect the programmer to explicitly use a
>"path.to_native" conversion function, to indicate that he doesn't
>actually MIND if the pathname get's munged up ( truncated | character
>translated | etc. ) as long as there is a determinate mapping.
>( for practical purposes one-to-one )

I don't understand this.  Pathnames hardcoded into programs are almost
always things like /etc/termcap, /usr/tmp or the equivalent of
$HOME/.mh_profile.  How would you expect a path.to_native for Mac or
MS-DOS to translate these?  You can *never* expect to be able to move
a program containing hardcoded pathnames to such a system without
having to edit them.

Filenames (i.e. no slash on UNIX) are a different matter, but even
there the choice of names usually has to be revised by a human being
when moving to a different O.S., e.g. names begginning with a . are
not usable on MS-DOS.

>I think we are in agreement on:
>(1) There will be ( for example ) a 'path' module for unix|dos|mac|etc.
>    that will attempt to hide or at least isolate machine differences.
>(2) That portable code should only need to import 'path', and not
>    need to figure out which 'specific' module ( unixpath|macpath|dospath )
>    it needs to load. [ I don't care what mechanics we choose to do this,
>    as long as we can hide the machinery! ]
>(3) But searching for module dependencies and renameing files is not
>    the preferred solution to the above. [ The machinery here is
>    painfully visible, even if only visible to ONE person ( the site
>    maintainer/installer of Python. ]

Yes.  Yes!  YES!!!

I will try to put a lot of this the a next release, or at least make a
decent attempt (after all I routinely move Python code between a Mac
and UNIX so I have ample opportunity to test it in two totally
different environments).

>[ BTW: I have managed to get my packet drivers working on my 486 PC,
>  So I can telnet the python sources onto it. I have the Gnu C compiler
>  PC port installed, So I hope to start porting Python *REAL SOON* ]

That's good news!

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"This is an ex-parrot"










Received: by charon.cwi.nl with SMTP; Fri, 7 Feb 1992 00:18:09 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa19071;
          6 Feb 92 18:17 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA09617; Thu, 6 Feb 92 18:08:49 EST
Date: Thu, 6 Feb 92 18:08:49 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Python portability planning ( and prototypes )

>
> >Where pathname need to be written into a program, then it is not
> >unreasonable to expect the programmer to explicitly use a
> >"path.to_native" conversion function, to indicate that he doesn't
> >actually MIND if the pathname get's munged up ( truncated | character
> >translated | etc. ) as long as there is a determinate mapping.
> >( for practical purposes one-to-one )
>
> I don't understand this.  Pathnames hardcoded into programs are almost
> always things like /etc/termcap, /usr/tmp or the equivalent of
> $HOME/.mh_profile.  How would you expect a path.to_native for Mac or
> MS-DOS to translate these?  You can *never* expect to be able to move
> a program containing hardcoded pathnames to such a system without
> having to edit them.

One case that is easy: Files that go into /tmp on unix should probably
go into \tmp on my dos machine. ( \tmp is not a necessary part of the
dos file tree, but quite a number of programs require it, or some logical
assignment of TEMP. I can think up other cases, but most of them are
a little more strained in terms of what is "reasonable" translation.
One other case that is not would be with relative pathnames in a package
that expected files to be in a definite "relative" path. ( Like for
example Python's own import search path! ). [ Actually, if you stick
to common denominator characters, you can already do this with the
path module. ]. The user may be expected to change the top level
directory, but not the whole set of path names used.

>
> Filenames (i.e. no slash on UNIX) are a different matter, but even
> there the choice of names usually has to be revised by a human being
> when moving to a different O.S., e.g. names begginning with a . are
> not usable on MS-DOS.
>

But, yes: *FILE* names, rather than *PATH* names are where MOST of the
translation is useful. Even useful interactively - some of us who jump
from system to system would RATHER be able to slip up and write a
unix style pathname and have it translated instead of getting an error.
But, again: I'm not asking for that as an automatic feature. Someone
should have to explicitly invoke it or explicitly alias open() to a
wrapper that does it. It should NOT be a default action to rename
peoples files into something else without warning them!!!


Bye - I've got to go celebrate Chinese New Year ( a few days late ) !
- Steve











Received: by charon.cwi.nl with SMTP; Fri, 7 Feb 1992 09:47:39 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01764; Fri, 7 Feb 92 03:46:53 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 023139.5112; Fri, 7 Feb 1992 02:31:39 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA02685; Fri, 7 Feb 92 02:21:08 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA09248; Fri, 7 Feb 92 02:21:07 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: And more stuff added to Emacs Python mode ...
Date: Fri, 07 Feb 92 02:21:06 EST
From: Tim Peters <[e-mail]>

Rather than burden y'all with a gazillabyte of new&improved Python-mode
every day, I'll just send the latest change log, and not broadcast the
code again until it settles down for a week.  Happy to send intermediate
versions on request (& if "too many" people request it, I'll just
broadcast it to the list instead).

The focus of the latest version is to allow blank lines & comment lines
"in the middle" without losing track of the proper indentation.  E.g.,

if whatever:
    print 'indenting this right is no trick'

            # some blank lines & a strangely-placed comment line

    print 'but this is'

Python mode handles this now.

The idea is that if Python accepts it without griping, so should Python-
mode.  The bulk of the changes actually had to do with esoteric
consequences of that principle, involving the sometimes darned-hard-to-
parse-backwards <grin> interactions among indentation, comment symbols,
and backslashes.  A couple examples of pathologies are given in the
change log below.

Uncomfortable but unavoidable side effect:  Suppose you type:

def oneplus(n):
    return 1+n
<an empty line>

The new Python mode, unlike the previous ones (which looked only at the
immediately preceding line), thinks the next line you type should be
indented to match the "return" line.  There's no general way to stop
this and still allow blank/empty lines where you want them -- the
paradox of Python-mode is that it wants to help you indent, but in
effect it needs you to tell it the proper indentation first since
there's no other way to figure out the grouping you intend (most other
language modes can figure out the grouping by looking at keywords and
bracketing constructs (begin/end if/endif {/} (/) etc) ...).

Question:  in looking over the to-do's at the bottom of the code, I
don't think I want to do this one:

- switch back to previous buffer when starting shell

That is, after "C-c !", I *like* winding up in the Python buffer (the
current behavior).  How do other people feel about that?

and-about-the-portability-thread-all-i-can-say-is-that-if-god-wanted-
   us-to-move-programs-from-machine-to-machine-he-wouldn't-have-
   invented-heart-disease<snort>-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

Latest python-mode.el change-log entry:

taught py-compute-indentation about blank & comment lines:
      accept comment line indentation as-is
      skip blank & comment lines when looking for the indentation of
          the preceding statement
      change py-shift-region docs accordingly
reversed order of change log (now most-recent first)
changed "\C-c\C-i" to "\C-c\t" for clarity
rearranged mode-map & syntax-table code to match other language modes
taught py-continuation-line-p that a trailing backslash does not
      indicate continuation when it ends a comment line
ditto py-goto-initial-line
fixed some pathological cases; e.g.,
      if \
        1 \
        :\
        \
        \
        # continued comment
      print 'I should be indented'
      if a == b : # \
      print 'I should be indented, but not like a continuation'
added consts py-stringlit-re and py-continued-re to support the above;
      made py-colon-line-re even hairier

>>> END OF MSG










Received: by charon.cwi.nl with SMTP; Fri, 7 Feb 1992 16:33:09 +0100
Received: by voorn.cwi.nl with SMTP; Fri, 7 Feb 1992 15:33:08 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: writing a Python extension module in C++
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 07 Feb 1992 16:33:07 +0100
Sender: [e-mail]

I've forgotten who asked about this, but I've just verified that it is
indeed possible to implement a Python extension module in C++.

All you really need to do is enclose the #includes of Python header
files in extern "C" { ... } and declare the only public C function of
the module (its initialization function) as extern "C".  Here's an
example ("trialmodule.C"):

------------------------------------------------------------------------
// An extension module for Python in C++

extern "C" {
    #include "allobjects.h"
    #include "modsupport.h"
}

static object* trial_test(object*, object* args) {
    if (!getnoarg(args)) NULL;
    printf("Hello, world!\n");
    INCREF(None);
    return None;
}

static struct methodlist trial_methods[] = {
    {"test",    (method)trial_test}, // *** cast! ***
    {NULL,        NULL}
};

extern "C" void inittrial() {
    initmodule("trial", trial_methods);
}
------------------------------------------------------------------------

There's one bit of uneasiness: the function pointer (trial_test) in
the initializer for trial_methods must be cast explicitly to method.
This is because the typedef for method in "methodobject.h" uses the
FPROTO() macro rather than PROTO() (both defined in "PROTO.h") which
makes the function prototype vanish, and C++ then believes it has no
arguments.  I may fix this in the next release.

It even works with the new dynamic loading I've added to Python 0.9.6!

Disclaimer: this is on an SGI with a reasonably modern C++ translator,
based on AT&T cfront 2.0.  I suppose a restriction will be that you
can't declare global objects with constructors or destructors, since
the Python main program is compiled by C, not by C++.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
Founder of the Royal Society for Prevention of Cruelty to Amoebae










To: [e-mail]
Subject: writing a Python extension module in C++
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 07 Feb 1992 16:33:07 +0100
Sender: guido

I've forgotten who asked about this, but I've just verified that it is
indeed possible to implement a Python extension module in C++.

All you really need to do is enclose the #includes of Python header
files in extern "C" { ... } and declare the only public C function of
the module (its initialization function) as extern "C".  Here's an
example ("trialmodule.C"):

------------------------------------------------------------------------
// An extension module for Python in C++

extern "C" {
    #include "allobjects.h"
    #include "modsupport.h"
}

static object* trial_test(object*, object* args) {
    if (!getnoarg(args)) NULL;
    printf("Hello, world!\n");
    INCREF(None);
    return None;
}

static struct methodlist trial_methods[] = {
    {"test",    (method)trial_test}, // *** cast! ***
    {NULL,        NULL}
};

extern "C" void inittrial() {
    initmodule("trial", trial_methods);
}
------------------------------------------------------------------------

There's one bit of uneasiness: the function pointer (trial_test) in
the initializer for trial_methods must be cast explicitly to method.
This is because the typedef for method in "methodobject.h" uses the
FPROTO() macro rather than PROTO() (both defined in "PROTO.h") which
makes the function prototype vanish, and C++ then believes it has no
arguments.  I may fix this in the next release.

It even works with the new dynamic loading I've added to Python 0.9.6!

Disclaimer: this is on an SGI with a reasonably modern C++ translator,
based on AT&T cfront 2.0.  I suppose a restriction will be that you
can't declare global objects with constructors or destructors, since
the Python main program is compiled by C, not by C++.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
Founder of the Royal Society for Prevention of Cruelty to Amoebae










Received: by charon.cwi.nl with SMTP; Sat, 8 Feb 1992 01:03:03 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01477; Fri, 7 Feb 92 19:02:12 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 180141.17588; Fri, 7 Feb 1992 18:01:41 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA09230; Fri, 7 Feb 92 17:48:55 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA14716; Fri, 7 Feb 92 17:48:54 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Emacs Python mode again
Date: Fri, 07 Feb 92 17:48:51 EST
From: Tim Peters <[e-mail]>

Added another function, to reformat existing code (to use the value of
py-indent-offset you like).  Easiest thing is to visit a file of old
code, then do

    C-x h C-c r

"C-x h" is ordinary Emacs that sets the region to the whole buffer, then
"C-c r" runs the new function py-reindent-top-level-region.  Here's the
doc string:

  "Reindent region with current value of py-indent-offset.
This is useful when you inherit Python code from someone who used
a silly (i.e., not yours) value for py-indent-offset, or just to see
what your code would look like if you changed your setting of py-
indent-offset.

The region is assumed to be correctly indented and to start with top-
level Python code (i.e., code that starts in the first column).  The
region is then reindented with the current value of py-indent-offset.

If you specify a numeric prefix argument, that will be used for the
indentation offset instead.

Special cases:  whitespace is deleted from entirely blank lines; and
continuation lines are shifted by the same amount their base line was
shifted, in order to preserve their relative indentation with respect to
their base line."

shiftily y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










Replied: Mon, 10 Feb 1992 10:49:24 +0100
Replied: "Tim Peters <[e-mail]> +inbox"
Received: by charon.cwi.nl with SMTP; Mon, 10 Feb 1992 00:02:19 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01492; Sun, 9 Feb 92 18:02:17 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 180123.29583; Sun, 9 Feb 1992 18:01:23 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA26267; Sun, 9 Feb 92 16:23:47 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA01145; Sun, 9 Feb 92 16:23:46 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Finally happy w/ indentation in Emacs Python mode
Date: Sun, 09 Feb 92 16:23:45 EST
From: Tim Peters <[e-mail]>

New version attached.  Give it a try, gripe at will.

C-c r has gone away, and an extended version of its functionality merged
into C-c TAB.  The mode blurb (C-h m) explanation of indentation has
been completely rewritten; read it, and also do `C-h k C-c TAB' to learn
about C-c TAB's fine points.

> [a funny guido .sig]
> "A quick survey of the literature will show that there are hundreds of
> language features to support abstract data types, but only one
> example--the stack" --Mark R. Brown and Greg Nelson

C-c TAB is now smart enough to bail you out after pasting together
Python code from a variety of sources using a variety of indentation
conventions.  E.g. `C-x h C-c TAB' will change this:

>>> BEGIN CONTRIVED EXAMPLE

EmptyStack = 'attempt to access empty stack'

class Stack:

  def init(s):
    s.data = []
    return s

  def push(s,v): s.data.append(v)

  def top(s):
      if len(s.data) = 0:
                  raise \
                 EmptyStack
      else:
      return s.data[-1]

  def pop(s):
   top = s.top()
   del s.data[-1:]
   return top

>>> END CONTRIVED EXAMPLE

into this (when py-indent-offset is 4, or 4 is given as a prefix arg to
C-c TAB):

>>> BEGIN TRANSFORMED CONTRIVED EXAMPLE

EmptyStack = 'attempt to access empty stack'

class Stack:

    def init(s):
    s.data = []
    return s

    def push(s,v): s.data.append(v)

    def top(s):
    if len(s.data) = 0:
        raise \
         EmptyStack
    else:
        return s.data[-1]

    def pop(s):
    top = s.top()
    del s.data[-1:]
    return top

>>> END TRANSFORMED CONTRIVED EXAMPLE

The meaning of a prefix argument to C-C TAB has also changed:  it used
to mean "shift everything in the region by that amount"; now it's used
as a temporary value for py-indent-offset.  C-c < and C-c > are the only
remaining ways to shift a region rigidly; C-c TAB now always
"normalizes" region indentation.

it's-easier-to-use-than-to-explain-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

;;; Major mode for editing Python programs.
;; by: Michael A. Guravage and Guido van Rossum <[e-mail]>
;;
;; The following statements, placed in your .emacs file or site-init.el,
;; will cause this file to be autoloaded, and python-mode invoked, when
;; visiting .py files (assuming the file is in your load-path):
;;
;;    (autoload 'python-mode "python-mode" "" t)
;;    (setq auto-mode-alist
;;          (cons '("\\.py$" . python-mode) auto-mode-alist))

;;; Change log:
;
; Sun Feb  9 02:35:11 1992  tim
; changed py-reindent-top-level-region so that it isn't confused by
;    seeing a mixture of different indentation styles in the region
; fixed potential infinite loop in py-reindent-top-level-region (if
;    the region doesn't end with a newline, (forward-line 1) always
;    returns a success value)
; merged py-shift-region and py-reindent-top-level-region and renamed
;    the combo py-indent-region, bound to C-c TAB
; completely rewrote the mode blurb's explanation of indentation
;
; Fri Feb  7 17:18:11 1992  tim
; added support for reindenting a region with a different value for
;    the indentation offset; new function py-reindent-top-level-region;
;    new docs; bound to C-c r.
; replaced the hard-coded tabs in the mode blurb with "\t"
;
; Fri Feb  7 01:13:08 1992  tim
; taught py-compute-indentation about blank & comment lines:
;    accept comment line indentation as-is
;    skip blank & comment lines when looking for the indentation of
;        the preceding statement
;    change py-shift-region docs accordingly
; reversed order of change log (now most-recent first)
; changed "\C-c\C-i" to "\C-c\t" for clarity
; rearranged mode-map & syntax-table code to match other language modes
; taught py-continuation-line-p that a trailing backslash does not
;    indicate continuation when it ends a comment line
; ditto py-goto-initial-line
; fixed some pathological cases; e.g.,
;    if \
;          1 \
;          :\
;          \
;          \
;          # continued comment
;        print 'I should be indented'
;    if a == b : # \
;        print 'I should be indented, but not like a continuation'
; added consts py-stringlit-re and py-continued-re to support the above;
;    made py-colon-line-re even hairier
;
; Wed Feb  5 21:52:15 1992  tim
; changed new doc strings so first line makes sense on its own
; new function py-shift-region; bound to C-c TAB
; new function py-shift-region-left; bound to C-c <
; new function py-shift-region-right; bound to C-c >
; reorganized mode blurb
; sped up py-continuation-line-p
;
; Wed Feb  5 03:23:31 1992  tim
; added support for auto-indenting of continuation lines:
;    new vrbl py-continuation-offset
;    new function py-continuation-line-p
;    new function py-goto-initial-line
;    new function py-compute-indentation
;    rewrote py-indent-line
; changed py-indent-line to refrain from modifying the buffer if the
;    indentation is already correct
; hid the hairy colon-line regexp in a const
; changed indent-region example to use legal Python
; documented all that
;
; Mon Feb  3 20:37:27 1992  tim
; renamed file to 'python-mode.el' for consistency with other Emacs
;    language modes; changed autoload instructions accordingly
; improved accuracy of new/changed docs
; changed py-python-command from defconst to defvar so .emacs can
;    override it if desired
; add warning about indent-region; suggest indent-rigidly
;
; Sun Feb  2 21:48:59 1992  tim
; renamed 'python-indent' to 'py-indent-offset' for internal consistency
; replaced regexp in py-indent-line so it no longer indents after
;    lines like:
;    a = b   # ok: # found
;    a = ': #'
;
; Sun Feb  2 02:08:47 1992  tim
; added support for user-defined indentation increment:
;     added python-indent variable
;    changed py-indent-line to indent python-indent columns
;    fixed small bug in py-indent-line (changed start of r.e.
;        from [^#] to [^#\n])
;    added py-delete-char function; bound to \177
;    changed mode blurb accordingly


(provide 'python)

;;; Constants and variables

(defvar py-python-command "python"
  "*UNIX shell command used to start Python interpreter")

(defvar py-indent-offset 4
  "*Indentation increment in Python mode")

(defvar py-continuation-offset 2
  "*Indentation (in addition to py-indent-offset) for continued lines")

(defvar py-mode-map nil "Keymap used in Python mode buffers")
(if py-mode-map
    ()
  (setq py-mode-map (make-sparse-keymap))
  (define-key py-mode-map "\C-c\C-c"    'py-execute-buffer)
  (define-key py-mode-map "\C-c|"    'py-execute-region)
  (define-key py-mode-map "\C-c!"    'py-shell)
  (define-key py-mode-map "\177"    'py-delete-char)
  (define-key py-mode-map "\C-c\t"    'py-indent-region)
  (define-key py-mode-map "\C-c<"    'py-shift-region-left)
  (define-key py-mode-map "\C-c>"    'py-shift-region-right))

(defvar py-mode-syntax-table nil "Python mode syntax table")
(if py-mode-syntax-table
    ()
  (setq py-mode-syntax-table (make-syntax-table))
  (set-syntax-table py-mode-syntax-table)
  (modify-syntax-entry ?\( "()")
  (modify-syntax-entry ?\) ")(")
  (modify-syntax-entry ?\[ "(]")
  (modify-syntax-entry ?\] ")[")
  (modify-syntax-entry ?\{ "(}")
  (modify-syntax-entry ?\} "){")
  (modify-syntax-entry ?\_ "w")
  (modify-syntax-entry ?\' "\"") ; single quote is string quote
  (modify-syntax-entry ?\` "$")     ; backquote is open and close paren
  (modify-syntax-entry ?\# "<")     ; hash starts comment
  (modify-syntax-entry ?\n ">")) ; newline ends comment

;; a statement in Python opens a new block iff it ends with a colon;
;; while conceptually trivial, quoted strings, continuation lines, and
;; comments make this hard.  E.g., consider the statement
;; if \
;;      1 \
;;      :\
;;      \
;;      \
;;      # comment
;; here we define some regexps to help

(defconst py-stringlit-re "'\\([^'\n\\]\\|\\\\.\\)*'"
  "regexp matching a Python string literal")

;; warning!:  when [^#'\n\\] was written as [^#'\n\\]+ (i.e., with a
;; '+' suffix), this appeared to run 100x slower in some bad cases.
(defconst py-colon-line-re
  (concat
    "\\(" "[^#'\n\\]" "\\|" py-stringlit-re "\\|" "\\\\\n" "\\)*"
    ":"
    "\\(" "[ \t]\\|\\\\\n" "\\)*"
    "\\(#.*\\)?" "$")
  "regexp matching Python statements opening a new block")

;; this is tricky because a trailing backslash does not mean
;; continuation if it's in a comment
(defconst py-continued-re
  (concat
   "\\(" "[^#'\n\\]" "\\|" py-stringlit-re "\\)*"
   "\\\\$")
  "regexp matching Python lines that are continued")

;;; General Functions

(defun python-mode nil
  "Major mode for editing Python files.

Paragraphs are separated by blank lines only.

\\[python-mode] calls the value of the variable py-mode-hook with no args,
if that value is non-nil.

INTERFACE TO PYTHON INTERPRETER

\\[py-execute-buffer]\tsends the entire buffer to the Python interpreter
\\[py-execute-region]\tsends the current region.
\\[py-shell]\tstarts a Python interpreter window; this will be used by
\tsubsequent \\[py-execute-buffer] or \\[py-execute-region] commands

VARIABLES

py-indent-offset\tindentation increment
py-continuation-offset\textra indentation given to continuation lines

py-continuation-offset is the additional indentation given to the first
continuation line in a multi-line statement.  Each subsequent
continuation line in the statement inherits its indentation from the
line that precedes it, so if you don't like the default indentation
given to the first continuation line, change it to something you do like
and Python-mode will automatically use that for the remaining
continuation lines (or, until you change the indentation again).

INDENTATION

Primarily for entering new code:
\t\\[indent-for-tab-command]\tindent line appropriately
\t\\[newline-and-indent]\tinsert newline, then indent
\t\\[py-delete-char]\treduce indentation, or delete single character

Primarily for reindenting existing code:
\t\\[py-indent-region]\treindent region to match its context
\t\\[py-shift-region-left]\tshift region left by py-indent-offset
\t\\[py-shift-region-right]\tshift region right by py-indent-offset

Unlike most programming languages, Python uses indentation, and only
indentation, to specify block structure.  Hence the indentation supplied
automatically by Python-mode is just an educated guess:  only you know
the block structure you intend, so only you can supply correct
indentation.

The \\[indent-for-tab-command] and \\[newline-and-indent] keys try to suggest plausible indentation, based on
the indentation of preceding statements.  E.g., assuming
py-indent-offset is 4, after you enter
\tif a > 0: \\[newline-and-indent]
the cursor will be moved to the position of the `x':
\tif a > 0:
\t    x
If you then enter `c = d' \\[newline-and-indent], the cursor will move
to
\tif a > 0:
\t    c = d
\t    x
Python-mode cannot know whether that's what you intended, or whether
\tif a > 0:
\t    c = d
\tx
was your intent.  In general, Python-mode either reproduces the
indentation of the preceding (non-blank and non-comment) statement, or
adds an extra py-indent-offset blanks if the preceding statement has
`:' as its last significant (non-whitespace and non-comment) character.

\\[py-delete-char] is handy after \\[newline-and-indent] to reduce excess indentation.  It reduces the
indentation of a line by py-indent-offset columns if point is at the
first non-blank character (if any) of a line, or at the end of an
entirely blank line; else it deletes the preceding character, converting
tabs to spaces as needed so that only one character position is deleted.

The remaining `indent' functions apply to a region of Python code.  They
assume the block structure (equals indentation, in Python) of the region
is correct, and alter the indentation in various ways while preserving
the block structure:

\\[py-indent-region] reindents a region to match its context and/or with a
different value for the indentation offset.  This is useful when code
blocks are moved or yanked, when enclosing control structures are
introduced or removed, or to reformat code using a new value for the
indentation offset.  See the function documentation for details.

Warning:  indent-region should not normally be used!  It calls \\[indent-for-tab-command]
repeatedly, and as explained above, \\[indent-for-tab-command] can't guess the block
structure you intend.

\\[py-shift-region-left] shifts the region left by py-indent-offset columns.

\\[py-shift-region-right] shifts the region right by py-indent-offset columns.

The two `shift' functions above also honor numeric prefix arguments; see
the individual function documentation for details.

MODE MAP
\\{py-mode-map}"

  (interactive)
  (kill-all-local-variables)
  (use-local-map py-mode-map)
  (set-syntax-table py-mode-syntax-table)
  (setq  major-mode 'python-mode  mode-name "Python")

  (mapcar (function (lambda (x)
              (make-local-variable (car x))
              (set (car x) (cdr x))))
      '( (paragraph-separate . "^[ \t\f]*$")
         (paragraph-start     . "^[ \t\f]*$")
         (require-final-newline . t)
         (comment-start .        "# ")
         (comment-start-skip .    "# *")
         (comment-column . 40)
         (indent-line-function . py-indent-line)))

  (run-hooks 'py-mode-hook))


;;; Functions that execute Python commands in a subprocess

(defun py-shell ()
  "Start an interactive Python interpreter in another window.
The variable py-python-command names the interpreter."
  (interactive)
  (require 'shell)
  (switch-to-buffer-other-window
   (make-shell "Python" py-python-command))
  (make-local-variable 'shell-prompt-pattern)
  (setq shell-prompt-pattern "^>>> \\|^\\.\\.\\. "))

(defun py-execute-region (start end)
  "Send the region between START and END to a Python interpreter.
If there is a *Python* process it is used."
  (interactive "r")
  (condition-case nil
      (process-send-string "Python" (buffer-substring start end))
    (error (shell-command-on-region start end py-python-command nil))))

(defun py-execute-buffer nil
  "Send the contents of the buffer to a Python interpreter.
If there is a *Python* process buffer it is used."
  (interactive)
  (py-execute-region (point-min) (point-max)))


;;; Functions for Python style indentation

(defun py-delete-char ()
  "Reduce indentation or delete character.
If at first non-blank character, or at end of blank line, reduce
indentation by py-indent-offset columns.  Else delete preceding
character, converting tabs to spaces."
  (interactive)
  (backward-delete-char-untabify
   (if (and
    (= (current-indentation) (current-column))
    (>= (current-indentation) py-indent-offset))
       py-indent-offset
     1)))

(defun py-indent-line ()
  "Fix the indentation of the current line according to Python rules."
  (interactive)
  (let ( (need (py-compute-indentation)) )
    (if (= (current-indentation) need)
    nil
      (beginning-of-line)
      (delete-horizontal-space)
      (indent-to need))))

;; go to first line of current statement; usually this is the line we're
;; on, but if we're on the 2nd or following lines of a continuation
;; block, we need to go up to the first line of the block
(defun py-goto-initial-line ()
  (while (py-continuation-line-p) (forward-line -1)))

;; t iff on continuation line == preceding line ends with backslash
;; that's not in a comment
(defun py-continuation-line-p ()
  (save-excursion
    (beginning-of-line)
    (and
     ;; use a cheap test first to avoid the regexp if possible
     ;; use 'eq' because char-after may return nil
     (eq (char-after (- (point) 2)) ?\\ )
     (progn
       (forward-line -1) ; since eq test passed, there is a line above
       (looking-at py-continued-re)))))

(defun py-compute-indentation ()
  (save-excursion
    (beginning-of-line)
    (cond
     ;; are we on a continuation line?
     ( (py-continuation-line-p)
       (forward-line -1)
       (if (py-continuation-line-p) ; on at least 3rd line in block
       (current-indentation)    ; so just continue the pattern
     ;; else on 2nd line in block, so indent more
     (+ (current-indentation) py-indent-offset
        py-continuation-offset)))
     ;; not on a continuation line

     ;; if at start of restriction, or on a comment line, assume they
     ;; intended whatever's there
     ( (or (bobp) (looking-at "[ \t]*#"))
       (current-indentation) )

     ;; else indentation based on that of the statement that precedes
     ;; us; use the first line of that statement to establish the base,
     ;; in case the user forced a non-std indentation for the
     ;; continuation lines (if any)
     ( t
       ;; skip back over blank & comment lines
       ;; note:  will skip a blank or comment line that happens to be
       ;; a continuation line too
       (re-search-backward "^[ \t]*[^ \t#\n]" (point-min) 1)
       (py-goto-initial-line)
       (if (looking-at py-colon-line-re)
       (+ (current-indentation) py-indent-offset)
     (current-indentation))))))

(defun py-shift-region (start end count)
  (save-excursion
    (goto-char end)   (beginning-of-line) (setq end (point))
    (goto-char start) (beginning-of-line) (setq start (point))
    (indent-rigidly start end count)))

(defun py-shift-region-left (start end &optional count)
  "Shift region of Python code to the left.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
shifted to the left, by py-indent-offset columns.

If a prefix argument is given, the region is instead shifted by that
many columns."
  (interactive "*r\nP")   ; region; raw prefix arg
  (py-shift-region start end
           (- (prefix-numeric-value
               (or count py-indent-offset)))))

(defun py-shift-region-right (start end &optional count)
  "Shift region of Python code to the right.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
shifted to the right, by py-indent-offset columns.

If a prefix argument is given, the region is instead shifted by that
many columns."
  (interactive "*r\nP")   ; region; raw prefix arg
  (py-shift-region start end (prefix-numeric-value
                  (or count py-indent-offset))))

(defun py-indent-region (start end &optional indent-offset)
  "Reindent a region of Python code.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
reindented.  If the first line of the region has a non-whitespace
character in the first column, the first line is left alone and the rest
of the region is reindented with respect to it.  Else the entire region
is reindented with respect to the (closest non-blank & non-comment)
statement immediately preceding the region.

This is useful when code blocks are moved or yanked, when enclosing
control structures are introduced or removed, or to reformat code using
a new value for the indentation offset.

If a numeric prefix argument is given, it will be used as the value of
the indentation offset.  Else the value of py-indent-offset will be
used.

Warning:  The region must be consistently indented before this function
is called!  This function does not compute proper indentation from
scratch (that's impossible in Python), it merely adjusts the existing
indentation to be correct in context.

Special cases:  whitespace is deleted from entirely blank lines;
continuation lines are shifted by the same amount their base line was
shifted, in order to preserve their relative indentation with respect to
their base line; and comment lines beginning in column 1 are ignored."

  (interactive "*r\nP") ; region; raw prefix arg
  (save-excursion
    (goto-char end)   (beginning-of-line) (setq end (point-marker))
    (goto-char start) (beginning-of-line)
    (let ( (py-indent-offset (prefix-numeric-value
                  (or indent-offset py-indent-offset)))
       (indents '(-1))    ; stack of active indent levels
       (target-column 0)    ; column to which to indent
       (base-shifted-by 0)    ; amount last base line was shifted
       (indent-base (if (looking-at "[ \t\n]")
                (py-compute-indentation)
              0))
       ci)
      (while (< (point) end)
    (setq ci (current-indentation))
    ;; figure out appropriate target column
    (cond
     ( (or (eq (following-char) ?#)    ; comment in column 1
           (looking-at "[ \t]*$"))    ; entirely blank
       (setq target-column 0))
     ( (py-continuation-line-p)    ; shift relative to base line
       (setq target-column (+ ci base-shifted-by)))
     (t                ; new base line
      (if (> ci (car indents))    ; going deeper; push it
          (setq indents (cons ci indents))
        ;; else we should have seen this indent before
        (setq indents (memq ci indents)) ; pop deeper indents
        (if (null indents)
        (error "Bad indentation in region, at line %d"
               (save-restriction
             (widen)
             (1+ (count-lines 1 (point)))))))
      (setq target-column (+ indent-base
                 (* py-indent-offset
                    (- (length indents) 2))))
      (setq base-shifted-by (- target-column ci))))
    ;; shift as needed
    (if (/= ci target-column)
        (progn
          (delete-horizontal-space)
          (indent-to target-column)))
    (forward-line 1))))
  (set-marker end nil))

;; To do:
;; - add a newline when executing buffer ending in partial line
;; - suppress prompts when executing regions
;; - switch back to previous buffer when starting shell
;; - support for ptags

>>> END OF MSG










Replied: Thu, 13 Feb 1992 11:02:36 +0100
Replied: "[e-mail] +inbox"
Received: by charon.cwi.nl with SMTP; Thu, 13 Feb 1992 03:12:31 +0100
Received: from uvacs.cs.virginia.edu by uvaarpa.Virginia.EDU id aa28762;
          12 Feb 92 21:11 EST
Received: from jade.cs.Virginia.EDU by uvacs.cs.Virginia.EDU (4.1/5.1.UVA)
    id AA17939; Wed, 12 Feb 92 21:10:35 EST
Posted-Date: Wed, 12 Feb 92 21:10:22 EST
Return-Path: <[e-mail]>
Received: by jade.cs.Virginia.EDU (4.1/SMI-2.0)
    id AA23722; Wed, 12 Feb 92 21:10:22 EST
Date: Wed, 12 Feb 92 21:10:22 EST
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Tcl vs. Python

Has anyone run timing benchmarks? We are strongly considering a move
to Python, but wish to know what will change with respect to speed.

For your information, we plan to run multiple interpreters on a Sparc
which will be connected to 2 SGIs.

Thanks for your help,
Steve










To: [e-mail]
Subject: Re: Tcl vs. Python
In-reply-to: Your message of "Wed, 12 Feb 1992 21:10:22 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 13 Feb 1992 11:02:37 +0100
Sender: guido

>Has anyone run timing benchmarks? We are strongly considering a move
>to Python, but wish to know what will change with respect to speed.

Long ago I compared the speed of a Python version of fac(n) with a
figures given by Ousterhout for an early version of Tcl.  On the only
machine to which both I and Ousterhout had access (a DECstation 3100)
execution of the Python version was about 3 times as fast.  The Python
function was this:

    def fac(n):
        if n == 1: return 1
        else: return n * fac(n-1)

and it took 1.3 msec/call; the equivalent Tcl (don't have the source
handy) took 3.6 msec/call.

I expect that a fair comparison of the speeds of Python and Tcl will
be hard: both have the property that complex operations (such as
regular expression matches) will run at the same speed as C (because
they are implemented in C), while simple things like "i = i+1" takes
forever compared to C.

Given what I know of the Tcl implementation, I expect that operations
using complex data will be slower in Tcl because they are represented
as strings that must be packed and unpacked (this is even true for
numbers).  Tcl also has to do more work decoding the commands because
they are parsed on the fly, during execution, while Python represents
them in binary.

However, Python programs take more time up front because the code is
parsed and `compiled' before it is executed.  Fortunately, the
compiled representation of a module is cached (for every module
"foo.py" there is a cache file "foo.pyc", saving a lot of parse time).
Also, Tcl uses tricks like allocating small buffers on the stack
instead of on the heap to reduce the number of malloc() and free()
calls, while Python allocates all objects except integers on the heap.
I can imagine that this might make a null routine call in Tcl faster
than the same in Python; however the figures of the 'fac' example
above (which is function call intensive) seem to imply that Python is
still faster.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"You're so *digital*, girl!" -- Neneh Cherry










Replied: Thu, 13 Feb 1992 11:07:59 +0100
Replied: "Your message of "Thu, 13 Feb 1992 11:03:16 MET."
Replied: <[e-mail]>  [e-mail]"
Received: by charon.cwi.nl with SMTP; Thu, 13 Feb 1992 11:03:18 +0100
Received: by voorn.cwi.nl with SMTP; Thu, 13 Feb 1992 10:03:17 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Tcl vs. Python
In-Reply-To: Your message of "Wed, 12 Feb 1992 21:10:22 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 13 Feb 1992 11:03:16 +0100
Sender: [e-mail]

>Has anyone run timing benchmarks? We are strongly considering a move
>to Python, but wish to know what will change with respect to speed.

Long ago I compared the speed of a Python version of fac(n) with a
figures given by Ousterhout for an early version of Tcl.  On the only
machine to which both I and Ousterhout had access (a DECstation 3100)
execution of the Python version was about 3 times as fast.  The Python
function was this:

    def fac(n):
        if n == 1: return 1
        else: return n * fac(n-1)

and it took 1.3 msec/call; the equivalent Tcl (don't have the source
handy) took 3.6 msec/call.

I expect that a fair comparison of the speeds of Python and Tcl will
be hard: both have the property that complex operations (such as
regular expression matches) will run at the same speed as C (because
they are implemented in C), while simple things like "i = i+1" takes
forever compared to C.

Given what I know of the Tcl implementation, I expect that operations
using complex data will be slower in Tcl because they are represented
as strings that must be packed and unpacked (this is even true for
numbers).  Tcl also has to do more work decoding the commands because
they are parsed on the fly, during execution, while Python represents
them in binary.

However, Python programs take more time up front because the code is
parsed and `compiled' before it is executed.  Fortunately, the
compiled representation of a module is cached (for every module
"foo.py" there is a cache file "foo.pyc", saving a lot of parse time).
Also, Tcl uses tricks like allocating small buffers on the stack
instead of on the heap to reduce the number of malloc() and free()
calls, while Python allocates all objects except integers on the heap.
I can imagine that this might make a null routine call in Tcl faster
than the same in Python; however the figures of the 'fac' example
above (which is function call intensive) seem to imply that Python is
still faster.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"You're so *digital*, girl!" -- Neneh Cherry










Received: by charon.cwi.nl with SMTP; Thu, 13 Feb 1992 11:08:03 +0100
Received: by voorn.cwi.nl with SMTP; Thu, 13 Feb 1992 10:08:01 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Tcl vs. Python
In-Reply-To: Your message of "Thu, 13 Feb 1992 11:03:16 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 13 Feb 1992 11:08:00 +0100
Sender: [e-mail]

Oops, I should have said that the benchmark called fac(5).
--Guido










Received: by charon.cwi.nl with SMTP; Mon, 17 Feb 1992 22:22:17 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27727; Mon, 17 Feb 92 16:22:14 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 162136.2323; Mon, 17 Feb 1992 16:21:36 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA01015; Mon, 17 Feb 92 16:06:58 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA16586; Mon, 17 Feb 92 16:06:57 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Version 1.0 of (Emacs) Python mode
Date: Mon, 17 Feb 92 16:06:56 EST
From: Tim Peters <[e-mail]>

Attached.  Many changes from the last version you saw, including an
obnoxious copyright notice that's as weak as possible without inviting
nuisance litigation.

The only major incompatibility with previous versions is that
py-indent-offset now defaults to 8.

New commands include:
    C-c C-n     go to next statement
    C-c C-p  go to previous statement
    LFD     in most ways unchanged
    C-c C-u     go to start of smallest enclosing code block
    C-c C-b  mark the next "interesting" block of lines
    C-c #     comment out a region of code
    C-u C-c #  uncomment a commented-out region of code

And almost everything else has changed in some small way or another in
response to various gripes.  Note especially that a convention has been
introduced for distinguishing between comments that should and shouldn't
affect the indentation of following lines.

The mode blurb (C-h m) has gotten huge; sorry about that.  An Emacs Info
node would be more appropriate, but I don't know how to write one &
don't have time to learn.

gripes-&-suggestions-welcome-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

The change log has been removed from the code.  Here are the entries
(most recent first) since the last version you saw:

Mon Feb 17 15:28:12 1992  tim
replaced '(point-min)' by 'nil' in a couple regexp search cmds (faster)
rewrote py-mark-block to be more useful
new helper py-goto-beyond-final-line
new const py-blank-or-comment-re
changed the docs accordingly
stuck in some `Emacs hints' since half the questions i get are
    really general Emacs questions
added copyright
added version number
removed change log

Sun Feb 16 01:03:32 1992  tim
changed 'provide' to provide 'python-mode, so that a plain
    (require 'python-mode) will work
changed binding of py-mark-block to C-c C-b (`C-c RET' was too confusing)
new function py-goto-block-up, bound to C-c C-u
changed py-newline-and-indent to try to act more like
    newline-and-indent usually acts in other language modes (obscure)

Sat Feb 15 00:05:33 1992  tim
minor code cleanups (no change in function)
removed old instances of \f, since Python doesn't accept formfeeds
changed py-compute-indentation to distinguish between two kinds
    of comment lines (indenting & non-indenting)
added to mode blurb, explaining the various terms used in the docs
    for talking about python lines & statements
changed all the docs to use those terms consistently
changed py-indent-offset default to 8, to humor Guido <grin>
added code to recognize embedded vi directive to change tabsize
    added new vrbl py-beep-if-tab-change
new function py-comment-region, bound to C-c #
    new supporting vrbl py-block-comment-prefix

Wed Feb 12 23:44:45 1992  tim
added function py-mark-block, bound to C-c C-m
added helper function py-suck-up-leading-text

Tue Feb 11 21:54:44 1992  tim
changed py-indent-line to leave point where the `Basic Indent' node
    of the Emacs docs sez TAB will leave it
added new function py-newline-and-indent, bound to LFD
         updated docs
added initialization code to search the global keymap for
    instances of newline-and-indent, and to shadow them
    by binding the same keys to py-newline-and-indent in
    the local py-mode-map (CAUTION:  not entirely sure I
    know all the implications)

Mon Feb 10 22:33:39 1992  tim
mentioned py-python-command in 'variable' section of mode blurb
fixed py-goto-initial-line so it always moves to start of line
rearranged some of the functions
added my name to the "who's to blame?" blurb
added new functions for moving point:
    py-goto-statement-at-or-above
    py-goto-statement-below
    py-next-statement; bound to C-c C-n
    py-previous-statement; bound to C-c C-p

And here's the code:

;;; Major mode for editing Python programs, version 1.00
;; by: Michael A. Guravage
;;     Guido van Rossum <[e-mail]>
;;     Tim Peters <[e-mail]>
;;
;; Copyright (c) 1992  Tim Peters
;;
;; This software is provided as-is, without express or implied warranty.
;; Permission to use, copy, modify, distribute or sell this software,
;; without fee, for any purpose and by any individual or organization, is
;; hereby granted, provided that the above copyright notice and this
;; paragraph appear in all copies.
;;
;;
;; The following statements, placed in your .emacs file or site-init.el,
;; will cause this file to be autoloaded, and python-mode invoked, when
;; visiting .py files (assuming the file is in your load-path):
;;
;;    (autoload 'python-mode "python-mode" "" t)
;;    (setq auto-mode-alist
;;          (cons '("\\.py$" . python-mode) auto-mode-alist))

(provide 'python-mode)

;;; Constants and variables

(defvar py-python-command "python"
  "*UNIX shell command used to start Python interpreter")

(defvar py-indent-offset 8        ; argue with Guido <grin>
  "*Indentation increment in Python mode")

(defvar py-continuation-offset 2
  "*Indentation (in addition to py-indent-offset) for continued lines")

(defvar py-block-comment-prefix "##"
  "*String used by py-comment-region to comment out a block of code")

(defvar py-beep-if-tab-change t
  "*Ring the bell if tab-width is changed")

(defvar py-mode-map nil "Keymap used in Python mode buffers")
(if py-mode-map
    ()
  (setq py-mode-map (make-sparse-keymap))

  ;; shadow global bindings for newline-and-indent w/ the py- version
  (mapcar (function (lambda (key)
              (define-key
            py-mode-map key 'py-newline-and-indent)))
   (where-is-internal 'newline-and-indent))

  (define-key py-mode-map "\C-c\C-c"    'py-execute-buffer)
  (define-key py-mode-map "\C-c|"    'py-execute-region)
  (define-key py-mode-map "\C-c!"    'py-shell)
  (define-key py-mode-map "\177"    'py-delete-char)
  (define-key py-mode-map "\n"        'py-newline-and-indent)
  (define-key py-mode-map "\C-c\t"    'py-indent-region)
  (define-key py-mode-map "\C-c<"    'py-shift-region-left)
  (define-key py-mode-map "\C-c>"    'py-shift-region-right)
  (define-key py-mode-map "\C-c\C-n"    'py-next-statement)
  (define-key py-mode-map "\C-c\C-p"    'py-previous-statement)
  (define-key py-mode-map "\C-c\C-u"    'py-goto-block-up)
  (define-key py-mode-map "\C-c\C-b"    'py-mark-block)
  (define-key py-mode-map "\C-c#"    'py-comment-region))


(defvar py-mode-syntax-table nil "Python mode syntax table")
(if py-mode-syntax-table
    ()
  (setq py-mode-syntax-table (make-syntax-table))
  (set-syntax-table py-mode-syntax-table)
  (modify-syntax-entry ?\( "()")
  (modify-syntax-entry ?\) ")(")
  (modify-syntax-entry ?\[ "(]")
  (modify-syntax-entry ?\] ")[")
  (modify-syntax-entry ?\{ "(}")
  (modify-syntax-entry ?\} "){")
  (modify-syntax-entry ?\_ "w")
  (modify-syntax-entry ?\' "\"") ; single quote is string quote
  (modify-syntax-entry ?\` "$")     ; backquote is open and close paren
  (modify-syntax-entry ?\# "<")     ; hash starts comment
  (modify-syntax-entry ?\n ">")) ; newline ends comment

;; a statement in Python opens a new block iff it ends with a colon;
;; while conceptually trivial, quoted strings, continuation lines, and
;; comments make this hard.  E.g., consider the statement
;; if \
;;      1 \
;;      :\
;;      \
;;      \
;;      # comment
;; here we define some regexps to help

(defconst py-stringlit-re "'\\([^'\n\\]\\|\\\\.\\)*'"
  "regexp matching a Python string literal")

;; warning!:  when [^#'\n\\] was written as [^#'\n\\]+ (i.e., with a
;; '+' suffix), this appeared to run 100x slower in some bad cases.
(defconst py-colon-line-re
  (concat
    "\\(" "[^#'\n\\]" "\\|" py-stringlit-re "\\|" "\\\\\n" "\\)*"
    ":"
    "\\(" "[ \t]\\|\\\\\n" "\\)*"
    "\\(#.*\\)?" "$")
  "regexp matching Python statements opening a new block")

;; this is tricky because a trailing backslash does not mean
;; continuation if it's in a comment
(defconst py-continued-re
  (concat
   "\\(" "[^#'\n\\]" "\\|" py-stringlit-re "\\)*"
   "\\\\$")
  "regexp matching Python lines that are continued")

(defconst py-blank-or-comment-re "[ \t]*\\($\\|#\\)"
  "regexp matching blank or comment lines")

;;; General Functions

(defun python-mode ()
  "Major mode for editing Python files.

Paragraphs are separated by blank lines only.

\\[python-mode] calls the value of the variable py-mode-hook with no
args, if that value is non-nil.

Obscure:  When python-mode is first loaded, it looks for all bindings to
newline-and-indent in the global keymap, and shadows them with local
bindings to py-newline-and-indent.

INTERFACE TO PYTHON INTERPRETER

\\[py-execute-buffer]\tsends the entire buffer to the Python interpreter
\\[py-execute-region]\tsends the current region.
\\[py-shell]\tstarts a Python interpreter window; this will be used by
\tsubsequent \\[py-execute-buffer] or \\[py-execute-region] commands

VARIABLES

If you don't like the default value for one of these, change its
value to whatever you do like by putting a `setq' line in your .emacs
file.  E.g., to set the indentation increment to 7, put this line in
your .emacs:
\t(setq  py-indent-offset  7)
To see the value of a variable, do `\\[describe-variable]' and enter the variable
name at the prompt.

py-python-command\tshell command to invoke Python interpreter
py-indent-offset\tindentation increment
py-continuation-offset\textra indentation given to continuation lines
py-block-comment-prefix\tcomment string used by `\\[py-comment-region]'
py-beep-if-tab-change\tring the bell if tab-width is changed

py-continuation-offset is the additional indentation given to the first
continuation line in a multi-line statement.  Each subsequent
continuation line in the statement inherits its indentation from the
line that precedes it, so if you don't like the default indentation
given to the first continuation line, change it to something you do like
and Python-mode will automatically use that for the remaining
continuation lines (or, until you change the indentation again).

If a comment of the form
\t# vi:set tabsize=<number>:
is found before the first code line when the file is entered, and
the current value of (the general Emacs variable) tab-width does not
equal <number>, tab-width is set to <number>, a message saying so is
displayed in the echo area, and if py-beep-if-tab-change is non-nil the
Emacs bell is also rung as a warning.

KINDS OF LINES

Each physical line in the file is either a `continuation line' (the
preceding line ends with a backslash that's not part of a comment) or an
`initial line' (everything else).

An initial line is in turn a `blank line' (contains nothing except
possibly blanks or tabs), a `comment line' (leftmost non-blank character
is `#'), or a `code line' (everything else).

Comment Lines

Although all comment lines are treated alike by Python, Python mode
recognizes two kinds that act differently with respect to indentation.

An `indenting comment line' is a comment line with a blank, tab or
nothing after the initial `#'.  The indentation commands (see below)
treat these exactly as if they were code lines:  a line following an
indenting comment line will be indented like the comment line.  All
other comment lines (those with a non-whitespace character immediately
following the initial `#') are `non-indenting comment lines', and their
indentation is ignored by the indentation commands.

Indenting comment lines are by far the usual case, and should be used
whenever possible.  Non-indenting comment lines are useful in cases like
these:

\ta = b   # a very wordy single-line comment that ends up being
\t        #... continued onto another line

\tif a == b:
##\t\tprint 'panic!' # old code we've `commented out'
\t\treturn a

Since the `#...' and `##' comment lines have a non-whitespace character
following the initial `#', Python mode ignores them when computing the
proper indentation for the next line.

Continuation Lines and Statements

The Python-mode commands generally work on statements instead of on
individual lines, where a `statement' is a comment or blank line, or a
code line and all of its following continuation lines (if any)
considered as a single logical unit.  The commands in this mode
generally (when it makes sense) automatically move to the start of the
statement containing point, even if point happens to be in the middle of
some continuation line.

A Bad Idea

Always put something on the initial line of a multi-line statement
besides the backslash!  E.g., don't do this:

\t\\
\ta = b # what's the indentation of this stmt?

While that's legal Python, it's silly & would be very expensive for
Python mode to handle correctly.


INDENTATION

Primarily for entering new code:
\t\\[indent-for-tab-command]\t indent line appropriately
\t\\[py-newline-and-indent]\t insert newline, then indent
\t\\[py-delete-char]\t reduce indentation, or delete single character

Primarily for reindenting existing code:
\t\\[py-indent-region]\t reindent region to match its context
\t\\[py-shift-region-left]\t shift region left by py-indent-offset
\t\\[py-shift-region-right]\t shift region right by py-indent-offset

Unlike most programming languages, Python uses indentation, and only
indentation, to specify block structure.  Hence the indentation supplied
automatically by Python-mode is just an educated guess:  only you know
the block structure you intend, so only you can supply correct
indentation.

The \\[indent-for-tab-command] and \\[py-newline-and-indent] keys try to suggest plausible indentation, based on
the indentation of preceding statements.  E.g., assuming
py-indent-offset is 4, after you enter
\tif a > 0: \\[py-newline-and-indent]
the cursor will be moved to the position of the `x':
\tif a > 0:
\t    x
If you then enter `c = d' \\[py-newline-and-indent], the cursor will move
to
\tif a > 0:
\t    c = d
\t    x
Python-mode cannot know whether that's what you intended, or whether
\tif a > 0:
\t    c = d
\tx
was your intent.  In general, Python-mode either reproduces the
indentation of the (closest code or indenting-comment) preceding
statement, or adds an extra py-indent-offset blanks if the preceding
statement has `:' as its last significant (non-whitespace and non-
comment) character.

\\[py-newline-and-indent] strives to `act like' the Emacs newline-and-indent function; this
requires some obscure Python-specific trickery because, as noted above,
it's not always possible to compute your intended indentation.

\\[py-delete-char] is handy after \\[py-newline-and-indent] to reduce excess indentation.  It reduces the
indentation of a line by py-indent-offset columns if point is at the
first non-blank character (if any) of a line, or at the end of a blank
line; else it deletes the preceding character, converting tabs to spaces
as needed so that only one character position is deleted.

The remaining `indent' functions apply to a region of Python code.  They
assume the block structure (equals indentation, in Python) of the region
is correct, and alter the indentation in various ways while preserving
the block structure:

`\\[py-indent-region]' reindents a region to match its context and/or with a
different value for the indentation offset.  This is useful when code
blocks are moved or yanked, when enclosing control structures are
introduced or removed, or to reformat code using a new value for the
indentation offset.  See the function documentation for details.

Warning:  indent-region should not normally be used!  It calls \\[indent-for-tab-command]
repeatedly, and as explained above, \\[indent-for-tab-command] can't guess the block
structure you intend.

`\\[py-shift-region-left]' shifts the region left by py-indent-offset columns.

`\\[py-shift-region-right]' shifts the region right by py-indent-offset columns.

The two `shift' functions above also honor numeric prefix arguments; see
the individual function documentation for details.

MARKING & MANIPULATING REGIONS OF CODE

\\[py-mark-block]\t mark block of lines
\\[py-comment-region]\t comment out region of code
\\[universal-argument] \\[py-comment-region]\t uncomment region of code

`\\[py-mark-block]' is easier to use than explain.  It sets the region to an
`interesting' block of succeeding lines.  If point is on a blank line,
it goes down to the next non-blank line.  That will be the start of the
region.  The end of the region depends on the kind of line at the start:

 - If a comment, the region will include all succeeding comment lines up
   to (but not including) the next non-comment line (if any).

 - If a code line that opens a new block, the region will include all
   succeeding lines up to (but not including) the next code statement
   (if any) that's indented no more than the starting line, except that
   trailing blank and comment lines are excluded.  E.g., if the starting
   line is a `def' statement, the region will be set to the full
   function definition, but without any trailing `noise' lines.

 - Else the region will include all succeeding lines up to (but not
   including) the next blank line, or code or indenting-comment line
   indented strictly less than the starting line.  Trailing indenting
   comment lines are included in this case, but not trailing blank
   lines.

`\\[py-comment-region]' comments out a region of code by inserting the string
py-block-comment-prefix at the start of each line.  If given a prefix
argument (like `\\[universal-argument]', which is kinda mnemonic for `uncomment'), it instead
deletes that string from the start of each line in the region.

MOVING POINT AROUND

\\[py-previous-statement]\t move to statement preceding point
\\[py-next-statement]\t move to statement following point
\\[py-goto-block-up]\t move up to start of current block

The first two move to one statement beyond the statement that contains
point.  A numeric prefix argument tells them to move that many
statements instead.  Blank lines, comment lines, and continuation lines
do not count as `statements' for these commands.  So, e.g., you can go
to the first code statement in a file by entering
\t\\[beginning-of-buffer]\t to move to the top of the file
\t\\[py-next-statement]\t to skip over initial comments and blank lines
Or do `\\[py-previous-statement]' with a huge prefix argument.

`\\[py-goto-block-up]' goes to the statement that starts the smallest enclosing block;
roughly speaking, this will be the closest preceding statement that ends
with a colon and is indented less than the statement you started on.
Also sets the mark to the starting point.

SOME LITTLE-KNOWN EMACS COMMANDS PARTICULARLY USEFUL IN PYTHON MODE

`\\[indent-new-comment-line]' is handy for entering a multi-line comment.

`\\[set-selective-display]' with a `small' prefix arg is ideally suited for seeing
the overall class and def structure of a module.

PYTHON-MODE's LOCAL KEYMAP
\\{py-mode-map}"

  (interactive)
  (kill-all-local-variables)
  (setq  major-mode 'python-mode  mode-name "Python")
  (use-local-map py-mode-map)
  (set-syntax-table py-mode-syntax-table)

  (mapcar (function (lambda (x)
              (make-local-variable (car x))
              (set (car x) (cdr x))))
      '( (paragraph-separate . "^[ \t]*$")
         (paragraph-start     . "^[ \t]*$")
         (require-final-newline . t)
         (comment-start .        "# ")
         (comment-start-skip .    "# *")
         (comment-column . 40)
         (indent-line-function . py-indent-line)))

  ;; hack to allow overriding the tabsize in the file (see tokenizer.c)

  ;; not sure where the magic comment has to be; to save time searching
  ;; for a rarity, we give up if it's not found prior to the first
  ;; executable statement
  (let ( (case-fold-search nil)
     new-tab-width)
    (if (re-search-forward
     "^[ \t]*#[ \t]*vi:set[ \t]+tabsize=\\([0-9]+\\):"
     (prog2 (py-next-statement 1) (point) (goto-char 1))
     t)
    (progn
      (setq new-tab-width
        (string-to-int
         (buffer-substring (match-beginning 1) (match-end 1))))
      (if (= tab-width new-tab-width)
          nil
        (setq tab-width new-tab-width)
        (message "Caution: tab-width changed to %d" new-tab-width)
        (if py-beep-if-tab-change (beep))))))

  (run-hooks 'py-mode-hook))

;;; Functions that execute Python commands in a subprocess

(defun py-shell ()
  "Start an interactive Python interpreter in another window.
The variable py-python-command names the interpreter."
  (interactive)
  (require 'shell)
  (switch-to-buffer-other-window
   (make-shell "Python" py-python-command))
  (make-local-variable 'shell-prompt-pattern)
  (setq shell-prompt-pattern "^>>> \\|^\\.\\.\\. "))

(defun py-execute-region (start end)
  "Send the region between START and END to a Python interpreter.
If there is a *Python* process it is used."
  (interactive "r")
  (condition-case nil
      (process-send-string "Python" (buffer-substring start end))
    (error (shell-command-on-region start end py-python-command nil))))

(defun py-execute-buffer nil
  "Send the contents of the buffer to a Python interpreter.
If there is a *Python* process buffer it is used."
  (interactive)
  (py-execute-region (point-min) (point-max)))


;;; Functions for Python style indentation

(defun py-delete-char ()
  "Reduce indentation or delete character.
If at first non-blank character, or at end of blank line, reduce
indentation by py-indent-offset columns.  Else delete preceding
character, converting tabs to spaces."
  (interactive)
  (backward-delete-char-untabify
   (if (and
    (= (current-indentation) (current-column))
    (>= (current-indentation) py-indent-offset))
       py-indent-offset
     1)))

(defun py-indent-line ()
  "Fix the indentation of the current line according to Python rules."
  (interactive)
  (let* ( (ci (current-indentation))
      (move-to-indentation-p (<= (current-column) ci))
      (need (py-compute-indentation)) )
    (if (/= ci need)
    (save-excursion
      (beginning-of-line)
      (delete-horizontal-space)
      (indent-to need)))
    (if move-to-indentation-p (back-to-indentation))))

(defun py-newline-and-indent ()
  "Strives to act like the Emacs newline-and-indent.
This is just `strives to' because correct indentation can't be computed
from scratch for Python code.  In general, deletes the whitespace before
point, inserts a newline, and takes an educated guess as to how you want
the new line indented."
  (interactive)
  (let ( (ci (current-indentation)) )
    (if (or (< ci (current-column))    ; if point is beyond indentation
        (looking-at "[ \t]*$"))    ; or line is empty
    (newline-and-indent)
      ;; else try to act like newline-and-indent "normally" acts
      (beginning-of-line)
      (insert-char ?\n 1)
      (move-to-column ci))))

(defun py-compute-indentation ()
  (save-excursion
    (beginning-of-line)
    (cond
     ;; are we on a continuation line?
     ( (py-continuation-line-p)
       (forward-line -1)
       (if (py-continuation-line-p) ; on at least 3rd line in block
       (current-indentation)    ; so just continue the pattern
     ;; else on 2nd line in block, so indent more
     (+ (current-indentation) py-indent-offset
        py-continuation-offset)))
     ;; not on a continuation line

     ;; if at start of restriction, or on a comment line, assume they
     ;; intended whatever's there
     ( (or (bobp) (looking-at "[ \t]*#"))
       (current-indentation) )

     ;; else indentation based on that of the statement that precedes
     ;; us; use the first line of that statement to establish the base,
     ;; in case the user forced a non-std indentation for the
     ;; continuation lines (if any)
     ( t
       ;; skip back over blank & non-indenting comment lines
       ;; note:  will skip a blank or non-indenting comment line that
       ;; happens to be a continuation line too
       (re-search-backward "^[ \t]*\\([^ \t\n#]\\|#[ \t\n]\\)"
               nil 'move)
       (py-goto-initial-line)
       (if (looking-at py-colon-line-re)
       (+ (current-indentation) py-indent-offset)
     (current-indentation))))))

(defun py-shift-region (start end count)
  (save-excursion
    (goto-char end)   (beginning-of-line) (setq end (point))
    (goto-char start) (beginning-of-line) (setq start (point))
    (indent-rigidly start end count)))

(defun py-shift-region-left (start end &optional count)
  "Shift region of Python code to the left.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
shifted to the left, by py-indent-offset columns.

If a prefix argument is given, the region is instead shifted by that
many columns."
  (interactive "*r\nP")   ; region; raw prefix arg
  (py-shift-region start end
           (- (prefix-numeric-value
               (or count py-indent-offset)))))

(defun py-shift-region-right (start end &optional count)
  "Shift region of Python code to the right.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
shifted to the right, by py-indent-offset columns.

If a prefix argument is given, the region is instead shifted by that
many columns."
  (interactive "*r\nP")   ; region; raw prefix arg
  (py-shift-region start end (prefix-numeric-value
                  (or count py-indent-offset))))

(defun py-indent-region (start end &optional indent-offset)
  "Reindent a region of Python code.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
reindented.  If the first line of the region has a non-whitespace
character in the first column, the first line is left alone and the rest
of the region is reindented with respect to it.  Else the entire region
is reindented with respect to the (closest code or indenting-comment)
statement immediately preceding the region.

This is useful when code blocks are moved or yanked, when enclosing
control structures are introduced or removed, or to reformat code using
a new value for the indentation offset.

If a numeric prefix argument is given, it will be used as the value of
the indentation offset.  Else the value of py-indent-offset will be
used.

Warning:  The region must be consistently indented before this function
is called!  This function does not compute proper indentation from
scratch (that's impossible in Python), it merely adjusts the existing
indentation to be correct in context.

Warning:  This function really has no idea what to do with non-indenting
comment lines, and shifts them as if they were indenting comment lines.
Fixing this appears to require telepathy.

Special cases:  whitespace is deleted from blank lines; continuation
lines are shifted by the same amount their initial line was shifted, in
order to preserve their relative indentation with respect to their
initial line; and comment lines beginning in column 1 are ignored."

  (interactive "*r\nP") ; region; raw prefix arg
  (save-excursion
    (goto-char end)   (beginning-of-line) (setq end (point-marker))
    (goto-char start) (beginning-of-line)
    (let ( (py-indent-offset (prefix-numeric-value
                  (or indent-offset py-indent-offset)))
       (indents '(-1))    ; stack of active indent levels
       (target-column 0)    ; column to which to indent
       (base-shifted-by 0)    ; amount last base line was shifted
       (indent-base (if (looking-at "[ \t\n]")
                (py-compute-indentation)
              0))
       ci)
      (while (< (point) end)
    (setq ci (current-indentation))
    ;; figure out appropriate target column
    (cond
     ( (or (eq (following-char) ?#)    ; comment in column 1
           (looking-at "[ \t]*$"))    ; entirely blank
       (setq target-column 0))
     ( (py-continuation-line-p)    ; shift relative to base line
       (setq target-column (+ ci base-shifted-by)))
     (t                ; new base line
      (if (> ci (car indents))    ; going deeper; push it
          (setq indents (cons ci indents))
        ;; else we should have seen this indent before
        (setq indents (memq ci indents)) ; pop deeper indents
        (if (null indents)
        (error "Bad indentation in region, at line %d"
               (save-restriction
             (widen)
             (1+ (count-lines 1 (point)))))))
      (setq target-column (+ indent-base
                 (* py-indent-offset
                    (- (length indents) 2))))
      (setq base-shifted-by (- target-column ci))))
    ;; shift as needed
    (if (/= ci target-column)
        (progn
          (delete-horizontal-space)
          (indent-to target-column)))
    (forward-line 1))))
  (set-marker end nil))

;;; Functions for moving point

(defun py-previous-statement (count)
  "Go to the start of previous Python statement.
If the statement at point is the i'th Python statement, goes to the
start of statement i-COUNT.  If there is no such statement, goes to the
first statement.  Returns count of statements left to move.
`Statements' do not include blank, comment, or continuation lines."
  (interactive "p") ; numeric prefix arg
  (if (< count 0) (py-next-statement (- count))
    (py-goto-initial-line)
    (let ( start )
      (while (and
          (setq start (point)) ; always true -- side effect
          (> count 0)
          (zerop (forward-line -1))
          (py-goto-statement-at-or-above))
    (setq count (1- count)))
      (if (> count 0) (goto-char start)))
    count))

(defun py-next-statement (count)
  "Go to the start of next Python statement.
If the statement at point is the i'th Python statement, goes to the
start of statement i+COUNT.  If there is no such statement, goes to the
last statement.  Returns count of statements left to move.  `Statements'
do not include blank, comment, or continuation lines."
  (interactive "p") ; numeric prefix arg
  (if (< count 0) (py-previous-statement (- count))
    (beginning-of-line)
    (let ( start )
      (while (and
          (setq start (point)) ; always true -- side effect
          (> count 0)
          (py-goto-statement-below))
    (setq count (1- count)))
      (if (> count 0) (goto-char start)))
    count))

(defun py-goto-block-up (&optional nomark)
  "Move up to start of current block.
Go to the statement that starts the smallest enclosing block; roughly
speaking, this will be the closest preceding statement that ends with a
colon and is indented less than the statement you started on.  If
successful, also sets the mark to the starting point.

`\\[py-mark-block]' can be used afterward to mark the whole code block, if desired.

If called from a program, the mark will not be set if optional argument
NOMARK is not nil."
  (interactive)
  (let ( (start (point))
     (found nil)
     initial-indent)
    (py-goto-initial-line)
    ;; if on blank or non-indenting comment line, use the preceding stmt
    (if (looking-at "[ \t]*\\($\\|#[^ \t\n]\\)")
    (progn
      (py-goto-statement-at-or-above)
      (setq found (looking-at py-colon-line-re))))
    ;; search back for colon line indented less
    (setq initial-indent (current-indentation))
    (while (not (or found (bobp)))
      (setq found
        (and
         (re-search-backward ":[ \t]*\\($\\|[#\\]\\)" nil 'move)
         (progn
           (py-goto-initial-line)
           (and
        (< (current-indentation) initial-indent)
        (looking-at py-colon-line-re))))))
    (if found
    (progn
      (or nomark (push-mark start))
      (back-to-indentation))
      (goto-char start)
      (error "Enclosing block not found"))))

;;; Functions for marking regions

(defun py-mark-block ()
  "Mark following block of lines.
Easier to use than explain.  It sets the region to an `interesting'
block of succeeding lines.  If point is on a blank line, it goes down to
the next non-blank line.  That will be the start of the region.  The end
of the region depends on the kind of line at the start:

 - If a comment, the region will include all succeeding comment lines up
   to (but not including) the next non-comment line (if any).

 - If a code line that opens a new block, the region will include all
   succeeding lines up to (but not including) the next code statement
   (if any) that's indented no more than the starting line, except that
   trailing blank and comment lines are excluded.  E.g., if the starting
   line is a `def' statement, the region will be set to the full
   function definition, but without any trailing `noise' lines.

 - Else the region will include all succeeding lines up to (but not
   including) the next blank line, or code or indenting-comment line
   indented strictly less than the starting line.  Trailing indenting
   comment lines are included in this case, but not trailing blank
   lines.

A msg identifying the location of the mark is displayed in the echo
area; or do `\\[exchange-point-and-mark]' to flip down to the end."
  (interactive)
  (py-goto-initial-line)
  ;; skip over blank lines
  (while (and
      (looking-at "[ \t]*$")    ; while blank line
      (not (eobp)))            ; & somewhere to go
    (forward-line 1))
  (if (eobp)
      (error "Hit end of buffer without finding a non-blank stmt"))
  (let ( (initial-pos (point))
     (initial-indent (current-indentation))
     last-pos)            ; position of last stmt in region
    (cond
     ;; if comment line, suck up the following comment lines
     ((looking-at "[ \t]*#")
      (re-search-forward "^[ \t]*[^ \t#]" nil 'move) ; look for non-comment
      (re-search-backward "^[ \t]*#")    ; and back to last comment in block
      (setq last-pos (point)))
     ;; else if line opens a block, search for next stmt indented <=
     ((looking-at py-colon-line-re)
      (while (and
          (setq last-pos (point))    ; always true -- side effect
          (py-goto-statement-below)
          (> (current-indentation) initial-indent))
    nil))
     ;; else plain code line; stop at next blank line, or stmt or
     ;; indenting comment line indented <
     (t
      (while (and
          (setq last-pos (point))    ; always true -- side effect
          (or (py-goto-beyond-final-line) t)
          (not (looking-at "[ \t]*$")) ; stop at blank line
          (or
           (>= (current-indentation) initial-indent)
           (looking-at "[ \t]*#[^ \t\n]"))) ; ignore non-indenting #
    nil)))

    ;; skip to end of last stmt
    (goto-char last-pos)
    (py-goto-beyond-final-line)
    ;; set mark & display
    (push-mark (point) 'no-msg)

    (forward-line -1)
    (message "Mark set after: %s" (py-suck-up-leading-text))

    (goto-char initial-pos)))

(defun py-comment-region (start end &optional uncomment-p)
  "Comment out region of code; with prefix arg, uncomment region.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
commented out, by inserting the string py-block-comment-prefix at the
start of each line.  With a prefix arg, removes py-block-comment-prefix
from the start of each line instead.  py-block-comment-prefix should be
of the form `#x...', where `x' is some character other than a blank or
a tab, and `...' is arbitrary.  This is so that the indentation commands
aren't confused by seeing these comments start in the leftmost column."
  (interactive "*r\nP")   ; region; raw prefix arg
  (goto-char end)   (beginning-of-line) (setq end (point))
  (goto-char start) (beginning-of-line) (setq start (point))
  (let ( (prefix-len (length py-block-comment-prefix)) )
    (save-excursion
      (save-restriction
    (narrow-to-region start end)
    (while (not (eobp))
      (if uncomment-p
          (and (string= py-block-comment-prefix
                (buffer-substring
                 (point) (+ (point) prefix-len)))
           (delete-char prefix-len))
        (insert py-block-comment-prefix))
      (forward-line 1))))))

;;; Helper functions

;; go to initial line of current statement; usually this is the
;; line we're on, but if we're on the 2nd or following lines of a
;; continuation block, we need to go up to the first line of the block
(defun py-goto-initial-line ()
  (while (py-continuation-line-p)
    (forward-line -1))
  (beginning-of-line))

;; go to point right beyond final line of current statement; usually
;; this is the start of the next line, but if this is a multi-line
;; statement we need to skip over the continuation lines
(defun py-goto-beyond-final-line ()
  (forward-line 1)
  (while (and (py-continuation-line-p)
          (not (eobp)))
    (forward-line 1)))

;; t iff on continuation line == preceding line ends with backslash
;; that's not in a comment
(defun py-continuation-line-p ()
  (save-excursion
    (beginning-of-line)
    (and
     ;; use a cheap test first to avoid the regexp if possible
     ;; use 'eq' because char-after may return nil
     (eq (char-after (- (point) 2)) ?\\ )
     (progn
       (forward-line -1) ; since eq test passed, there is a line above
       (looking-at py-continued-re)))))

;; go to start of first statement (not blank or comment or continuation
;; line) at or preceding point
;; returns t if there is one, else nil
(defun py-goto-statement-at-or-above ()
  (py-goto-initial-line)
  (if (looking-at py-blank-or-comment-re)
    ;; skip back over blank & comment lines
    ;; note:  will skip a blank or comment line that happens to be
    ;; a continuation line too
    (if (re-search-backward "^[ \t]*[^ \t#\n]" nil t)
        (progn (py-goto-initial-line) t)
      nil)
    t))

;; go to start of first statement (not blank or comment or continuation
;; line) following the statement containing point
;; returns t if there is one, else nil
(defun py-goto-statement-below ()
  (beginning-of-line)
  (let ( (start (point)) )
    (forward-line 1)
    (while (and
        (py-continuation-line-p)
        (not (eobp)))
      (forward-line 1))
    (while (and
        (looking-at py-blank-or-comment-re)
        (not (eobp)))
      (forward-line 1))
    (if (eobp)
    (progn (goto-char start) nil)
      t)))

;; return string in buffer from start of indentation to end of line;
;; prefix "..." if leading whitespace was skipped
(defun py-suck-up-leading-text ()
  (save-excursion
    (back-to-indentation)
    (concat
     (if (bolp) "" "...")
     (buffer-substring (point) (progn (end-of-line) (point))))))

;; To do:
;; - add a newline when executing buffer ending in partial line
;; - suppress prompts when executing regions
;; - switch back to previous buffer when starting shell
;; - support for ptags

>>> END OF MSG










Replied: Wed, 19 Feb 1992 11:10:03 +0100
Replied: "Tim Peters <[e-mail]> +inbox"
Received: by charon.cwi.nl with SMTP; Wed, 19 Feb 1992 06:02:25 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA24936; Wed, 19 Feb 92 00:02:19 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 000151.17724; Wed, 19 Feb 1992 00:01:51 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA19410; Tue, 18 Feb 92 23:25:43 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA07043; Tue, 18 Feb 92 23:25:41 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: (Emacs) Python mode, version 1.01
Date: Tue, 18 Feb 92 23:25:41 EST
From: Tim Peters <[e-mail]>

Sorry for posting this again so soon, but Guido pushed me into doing
some (what I think is) very valuable stuff, and you'll like it <grin>.

Question:  If anyone who is interested in python-mode.el does *not* have,
or know how to use, the 'patch' program, please let me know.  Context
diffs are generally much smaller than reposting the whole thing, and I'll
do that in the future unless somebody can't handle it.  In this
particular case the diff would be larger than the file, though ...

New stuff:

  - DEL is much smarter.  When you use it to reduce indentation, it now
    tells you which code block you're closing, and reduces the
    indentation to match that of the opening line of the block (so a
    non-uniform pattern of indentation increments won't confuse it).
    And if you use it to reduce indentation on a continuation or non-
    indenting comment line, it will delete just one column at a time (so
    you can use DEL and SPACE to adjust the indentation to exactly what
    you want in a straightforward way).

  - The mode blurb (C-h m) comes up much (about 20 times) faster now.
    Alas, this was bought at the cost of taking almost everything out
    of it <grin/sigh>.

  - A new&improved (but slow) "long" mode blurb can be gotten via the
    new `C-c C-h m'.  This is even longer than before, but is (I think)
    improved in several ways.  E.g., the current values of the mode
    variables are shown, you can search for the character '@' to move
    among major sections, and the guts of the "leaf" sections exactly
    match what you'd get if you did `C-h v' and `C-h f (or k)' one name
    at a time (before, in a futile effort to save space & time, `C-h m'
    often failed to tell the whole story).

Note that this mode is getting fancy enough that byte-compile'ing it has
a real speed payoff.  You do that by going into the directory containing
the .el file and entering

    emacs -batch -f batch-byte-compile python-mode.el

That will create python-mode.elc, and Emacs will load the .elc version
first when one exists (i.e., the line above is all you have to do; the
rest is magic).

darned-glad-python-creates-.pyc's-all-by-itself-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

Change log:

Tue Feb 18 22:35:04 1992  tim
version 1.01
simplified py-goto-statement-below by calling py-goto-beyond-final-line
changed py-compute-indentation to treat indenting comment lines
    exactly like code lines
forced early exit in py-goto-block-up if starting indent is 0
rewrote py-delete-char to be a lot smarter
    caters to non-std indentation (takes from first line in block)
    displays the 1st line of the block being closed
updated the docs accordingly
rewrote the `C-h m' support completely:
    `C-h m' made very bare but very fast
    new func py-describe-mode does the slow wordy stuff,
        bound to C-c C-h m
    new helper py-dump-help-string
    changed so vrbl & cmd docs are ripped directly out of the
        vrbls & cmds in question (so no more will C-h v or C-h f
        say one thing but C-h m say another)
    changed so all current key bindings are shown for cmds and so
        current values are shown for vrbls
    stuck '@' in front of major sections to aid in skipping around
        the help file
    rearranged several parts the way Guido did in his copy

;;; Major mode for editing Python programs, version 1.01
;; by: Michael A. Guravage
;;     Guido van Rossum <[e-mail]>
;;     Tim Peters <[e-mail]>
;;
;; Copyright (c) 1992  Tim Peters
;;
;; This software is provided as-is, without express or implied warranty.
;; Permission to use, copy, modify, distribute or sell this software,
;; without fee, for any purpose and by any individual or organization, is
;; hereby granted, provided that the above copyright notice and this
;; paragraph appear in all copies.
;;
;;
;; The following statements, placed in your .emacs file or site-init.el,
;; will cause this file to be autoloaded, and python-mode invoked, when
;; visiting .py files (assuming the file is in your load-path):
;;
;;    (autoload 'python-mode "python-mode" "" t)
;;    (setq auto-mode-alist
;;          (cons '("\\.py$" . python-mode) auto-mode-alist))

(provide 'python-mode)

;;; Constants and variables

(defvar py-python-command "python"
  "*Shell command used to start Python interpreter.")

(defvar py-indent-offset 8        ; argue with Guido <grin>
  "*Indentation increment.")

(defvar py-continuation-offset 2
  "*Indentation (in addition to py-indent-offset) for continued lines.
The additional indentation given to the first continuation line in a
multi-line statement.  Each subsequent continuation line in the
statement inherits its indentation from the line that precedes it, so if
you don't like the default indentation given to the first continuation
line, change it to something you do like and Python-mode will
automatically use that for the remaining continuation lines (or, until
you change the indentation again).")

(defvar py-block-comment-prefix "##"
  "*String used by py-comment-region to comment out a block of code.
This should follow the convention for non-indenting comment lines so
that the indentation commands won't get confused (i.e., the string
should be of the form `#x...' where `x' is not a blank or a tab, and
`...' is arbitrary).")

(defvar py-beep-if-tab-change t
  "*Ring the bell if tab-width is changed.
If a comment of the form
\t# vi:set tabsize=<number>:
is found before the first code line when the file is entered, and
the current value of (the general Emacs variable) tab-width does not
equal <number>, tab-width is set to <number>, a message saying so is
displayed in the echo area, and if py-beep-if-tab-change is non-nil the
Emacs bell is also rung as a warning.")

(defvar py-mode-map nil "Keymap used in Python mode buffers.")
(if py-mode-map
    ()
  (setq py-mode-map (make-sparse-keymap))

  ;; shadow global bindings for newline-and-indent w/ the py- version
  (mapcar (function (lambda (key)
              (define-key
            py-mode-map key 'py-newline-and-indent)))
   (where-is-internal 'newline-and-indent))

  (define-key py-mode-map "\C-c\C-c"    'py-execute-buffer)
  (define-key py-mode-map "\C-c|"    'py-execute-region)
  (define-key py-mode-map "\C-c!"    'py-shell)
  (define-key py-mode-map "\177"    'py-delete-char)
  (define-key py-mode-map "\n"        'py-newline-and-indent)
  (define-key py-mode-map "\C-c\t"    'py-indent-region)
  (define-key py-mode-map "\C-c<"    'py-shift-region-left)
  (define-key py-mode-map "\C-c>"    'py-shift-region-right)
  (define-key py-mode-map "\C-c\C-n"    'py-next-statement)
  (define-key py-mode-map "\C-c\C-p"    'py-previous-statement)
  (define-key py-mode-map "\C-c\C-u"    'py-goto-block-up)
  (define-key py-mode-map "\C-c\C-b"    'py-mark-block)
  (define-key py-mode-map "\C-c#"    'py-comment-region)
  (define-key py-mode-map "\C-c\C-hm"    'py-describe-mode))

(defvar py-mode-syntax-table nil "Python mode syntax table")
(if py-mode-syntax-table
    ()
  (setq py-mode-syntax-table (make-syntax-table))
  (set-syntax-table py-mode-syntax-table)
  (modify-syntax-entry ?\( "()")
  (modify-syntax-entry ?\) ")(")
  (modify-syntax-entry ?\[ "(]")
  (modify-syntax-entry ?\] ")[")
  (modify-syntax-entry ?\{ "(}")
  (modify-syntax-entry ?\} "){")
  (modify-syntax-entry ?\_ "w")
  (modify-syntax-entry ?\' "\"") ; single quote is string quote
  (modify-syntax-entry ?\` "$")     ; backquote is open and close paren
  (modify-syntax-entry ?\# "<")     ; hash starts comment
  (modify-syntax-entry ?\n ">")) ; newline ends comment

;; a statement in Python opens a new block iff it ends with a colon;
;; while conceptually trivial, quoted strings, continuation lines, and
;; comments make this hard.  E.g., consider the statement
;; if \
;;      1 \
;;      :\
;;      \
;;      \
;;      # comment
;; here we define some regexps to help

(defconst py-stringlit-re "'\\([^'\n\\]\\|\\\\.\\)*'"
  "regexp matching a Python string literal")

;; warning!:  when [^#'\n\\] was written as [^#'\n\\]+ (i.e., with a
;; '+' suffix), this appeared to run 100x slower in some bad cases.
(defconst py-colon-line-re
  (concat
    "\\(" "[^#'\n\\]" "\\|" py-stringlit-re "\\|" "\\\\\n" "\\)*"
    ":"
    "\\(" "[ \t]\\|\\\\\n" "\\)*"
    "\\(#.*\\)?" "$")
  "regexp matching Python statements opening a new block")

;; this is tricky because a trailing backslash does not mean
;; continuation if it's in a comment
(defconst py-continued-re
  (concat
   "\\(" "[^#'\n\\]" "\\|" py-stringlit-re "\\)*"
   "\\\\$")
  "regexp matching Python lines that are continued")

(defconst py-blank-or-comment-re "[ \t]*\\($\\|#\\)"
  "regexp matching blank or comment lines")

;;; General Functions

(defun python-mode ()
  "Major mode for editing Python files.
Do `\\[py-describe-mode]' for detailed documentation.
Knows about Python tokens, comments and continuation lines.
Paragraphs are separated by blank lines only.

COMMANDS
\\{py-mode-map}
VARIABLES

py-python-command\tshell command to invoke Python interpreter
py-indent-offset\tindentation increment
py-continuation-offset\textra indentation given to continuation lines
py-block-comment-prefix\tcomment string used by py-comment-region
py-beep-if-tab-change\tring the bell if tab-width is changed"
  (interactive)
  (kill-all-local-variables)
  (setq  major-mode 'python-mode  mode-name "Python")
  (use-local-map py-mode-map)
  (set-syntax-table py-mode-syntax-table)

  (mapcar (function (lambda (x)
              (make-local-variable (car x))
              (set (car x) (cdr x))))
      '( (paragraph-separate . "^[ \t]*$")
         (paragraph-start     . "^[ \t]*$")
         (require-final-newline . t)
         (comment-start .        "# ")
         (comment-start-skip .    "# *")
         (comment-column . 40)
         (indent-line-function . py-indent-line)))

  ;; hack to allow overriding the tabsize in the file (see tokenizer.c)

  ;; not sure where the magic comment has to be; to save time searching
  ;; for a rarity, we give up if it's not found prior to the first
  ;; executable statement
  (let ( (case-fold-search nil)
     new-tab-width)
    (if (re-search-forward
     "^[ \t]*#[ \t]*vi:set[ \t]+tabsize=\\([0-9]+\\):"
     (prog2 (py-next-statement 1) (point) (goto-char 1))
     t)
    (progn
      (setq new-tab-width
        (string-to-int
         (buffer-substring (match-beginning 1) (match-end 1))))
      (if (= tab-width new-tab-width)
          nil
        (setq tab-width new-tab-width)
        (message "Caution: tab-width changed to %d" new-tab-width)
        (if py-beep-if-tab-change (beep))))))

  (run-hooks 'py-mode-hook))

;;; Functions that execute Python commands in a subprocess

(defun py-shell ()
  "Start an interactive Python interpreter in another window.
The variable py-python-command names the interpreter."
  (interactive)
  (require 'shell)
  (switch-to-buffer-other-window
   (make-shell "Python" py-python-command))
  (make-local-variable 'shell-prompt-pattern)
  (setq shell-prompt-pattern "^>>> \\|^\\.\\.\\. "))

(defun py-execute-region (start end)
  "Send the region between START and END to a Python interpreter.
If there is a *Python* process it is used."
  (interactive "r")
  (condition-case nil
      (process-send-string "Python" (buffer-substring start end))
    (error (shell-command-on-region start end py-python-command nil))))

(defun py-execute-buffer nil
  "Send the contents of the buffer to a Python interpreter.
If there is a *Python* process buffer it is used."
  (interactive)
  (py-execute-region (point-min) (point-max)))


;;; Functions for Python style indentation

(defun py-delete-char ()
  "Reduce indentation or delete character.
If point is at the leftmost column, deletes the preceding newline.

Else if point is at the leftmost non-blank character of a line that is
neither a continuation line nor a non-indenting comment line, or if
point is at the end of a blank line, reduces the indentation to match
that of the line that opened the current block of code.  The line that
opened the block is displayed in the echo area to help you keep track of
where you are.

Else the preceding character is deleted, converting a tab to spaces if
needed so that only a single column position is deleted."
  (interactive "*")
  (if (or (/= (current-indentation) (current-column))
      (bolp)
      (py-continuation-line-p)
      (looking-at "#[^ \t\n]"))    ; non-indenting #
      (backward-delete-char-untabify 1)
    ;; else indent the same as the colon line that opened the block

    ;; force non-blank so py-goto-block-up doesn't ignore it
    (insert-char ?* 1)
    (backward-char)
    (let ( (base-indent 0)        ; indentation of base line
       (base-text "")        ; and text of base line
       (base-found-p nil))
      (condition-case nil        ; in case no enclosing block
      (save-excursion
        (py-goto-block-up 'no-mark)
        (setq base-indent (current-indentation)
          base-text   (py-suck-up-leading-text)
          base-found-p t))
    (error nil))
      (delete-char 1)            ; toss the dummy character
      (delete-horizontal-space)
      (indent-to base-indent)
      (if base-found-p
      (message "Closes block: %s" base-text)))))

(defun py-indent-line ()
  "Fix the indentation of the current line according to Python rules."
  (interactive)
  (let* ( (ci (current-indentation))
      (move-to-indentation-p (<= (current-column) ci))
      (need (py-compute-indentation)) )
    (if (/= ci need)
    (save-excursion
      (beginning-of-line)
      (delete-horizontal-space)
      (indent-to need)))
    (if move-to-indentation-p (back-to-indentation))))

(defun py-newline-and-indent ()
  "Strives to act like the Emacs newline-and-indent.
This is just `strives to' because correct indentation can't be computed
from scratch for Python code.  In general, deletes the whitespace before
point, inserts a newline, and takes an educated guess as to how you want
the new line indented."
  (interactive)
  (let ( (ci (current-indentation)) )
    (if (or (< ci (current-column))    ; if point is beyond indentation
        (looking-at "[ \t]*$"))    ; or line is empty
    (newline-and-indent)
      ;; else try to act like newline-and-indent "normally" acts
      (beginning-of-line)
      (insert-char ?\n 1)
      (move-to-column ci))))

(defun py-compute-indentation ()
  (save-excursion
    (beginning-of-line)
    (cond
     ;; are we on a continuation line?
     ( (py-continuation-line-p)
       (forward-line -1)
       (if (py-continuation-line-p) ; on at least 3rd line in block
       (current-indentation)    ; so just continue the pattern
     ;; else on 2nd line in block, so indent more
     (+ (current-indentation) py-indent-offset
        py-continuation-offset)))
     ;; not on a continuation line

     ;; if at start of restriction, or on a non-indenting comment line,
     ;; assume they intended whatever's there
     ( (or (bobp) (looking-at "[ \t]*#[^ \t\n]"))
       (current-indentation) )

     ;; else indentation based on that of the statement that precedes
     ;; us; use the first line of that statement to establish the base,
     ;; in case the user forced a non-std indentation for the
     ;; continuation lines (if any)
     ( t
       ;; skip back over blank & non-indenting comment lines
       ;; note:  will skip a blank or non-indenting comment line that
       ;; happens to be a continuation line too
       (re-search-backward "^[ \t]*\\([^ \t\n#]\\|#[ \t\n]\\)"
               nil 'move)
       (py-goto-initial-line)
       (if (looking-at py-colon-line-re)
       (+ (current-indentation) py-indent-offset)
     (current-indentation))))))

(defun py-shift-region (start end count)
  (save-excursion
    (goto-char end)   (beginning-of-line) (setq end (point))
    (goto-char start) (beginning-of-line) (setq start (point))
    (indent-rigidly start end count)))

(defun py-shift-region-left (start end &optional count)
  "Shift region of Python code to the left.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
shifted to the left, by py-indent-offset columns.

If a prefix argument is given, the region is instead shifted by that
many columns."
  (interactive "*r\nP")   ; region; raw prefix arg
  (py-shift-region start end
           (- (prefix-numeric-value
               (or count py-indent-offset)))))

(defun py-shift-region-right (start end &optional count)
  "Shift region of Python code to the right.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
shifted to the right, by py-indent-offset columns.

If a prefix argument is given, the region is instead shifted by that
many columns."
  (interactive "*r\nP")   ; region; raw prefix arg
  (py-shift-region start end (prefix-numeric-value
                  (or count py-indent-offset))))

(defun py-indent-region (start end &optional indent-offset)
  "Reindent a region of Python code.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
reindented.  If the first line of the region has a non-whitespace
character in the first column, the first line is left alone and the rest
of the region is reindented with respect to it.  Else the entire region
is reindented with respect to the (closest code or indenting-comment)
statement immediately preceding the region.

This is useful when code blocks are moved or yanked, when enclosing
control structures are introduced or removed, or to reformat code using
a new value for the indentation offset.

If a numeric prefix argument is given, it will be used as the value of
the indentation offset.  Else the value of py-indent-offset will be
used.

Warning:  The region must be consistently indented before this function
is called!  This function does not compute proper indentation from
scratch (that's impossible in Python), it merely adjusts the existing
indentation to be correct in context.

Warning:  This function really has no idea what to do with non-indenting
comment lines, and shifts them as if they were indenting comment lines.
Fixing this appears to require telepathy.

Special cases:  whitespace is deleted from blank lines; continuation
lines are shifted by the same amount their initial line was shifted, in
order to preserve their relative indentation with respect to their
initial line; and comment lines beginning in column 1 are ignored."

  (interactive "*r\nP") ; region; raw prefix arg
  (save-excursion
    (goto-char end)   (beginning-of-line) (setq end (point-marker))
    (goto-char start) (beginning-of-line)
    (let ( (py-indent-offset (prefix-numeric-value
                  (or indent-offset py-indent-offset)))
       (indents '(-1))    ; stack of active indent levels
       (target-column 0)    ; column to which to indent
       (base-shifted-by 0)    ; amount last base line was shifted
       (indent-base (if (looking-at "[ \t\n]")
                (py-compute-indentation)
              0))
       ci)
      (while (< (point) end)
    (setq ci (current-indentation))
    ;; figure out appropriate target column
    (cond
     ( (or (eq (following-char) ?#)    ; comment in column 1
           (looking-at "[ \t]*$"))    ; entirely blank
       (setq target-column 0))
     ( (py-continuation-line-p)    ; shift relative to base line
       (setq target-column (+ ci base-shifted-by)))
     (t                ; new base line
      (if (> ci (car indents))    ; going deeper; push it
          (setq indents (cons ci indents))
        ;; else we should have seen this indent before
        (setq indents (memq ci indents)) ; pop deeper indents
        (if (null indents)
        (error "Bad indentation in region, at line %d"
               (save-restriction
             (widen)
             (1+ (count-lines 1 (point)))))))
      (setq target-column (+ indent-base
                 (* py-indent-offset
                    (- (length indents) 2))))
      (setq base-shifted-by (- target-column ci))))
    ;; shift as needed
    (if (/= ci target-column)
        (progn
          (delete-horizontal-space)
          (indent-to target-column)))
    (forward-line 1))))
  (set-marker end nil))

;;; Functions for moving point

(defun py-previous-statement (count)
  "Go to the start of previous Python statement.
If the statement at point is the i'th Python statement, goes to the
start of statement i-COUNT.  If there is no such statement, goes to the
first statement.  Returns count of statements left to move.
`Statements' do not include blank, comment, or continuation lines."
  (interactive "p") ; numeric prefix arg
  (if (< count 0) (py-next-statement (- count))
    (py-goto-initial-line)
    (let ( start )
      (while (and
          (setq start (point)) ; always true -- side effect
          (> count 0)
          (zerop (forward-line -1))
          (py-goto-statement-at-or-above))
    (setq count (1- count)))
      (if (> count 0) (goto-char start)))
    count))

(defun py-next-statement (count)
  "Go to the start of next Python statement.
If the statement at point is the i'th Python statement, goes to the
start of statement i+COUNT.  If there is no such statement, goes to the
last statement.  Returns count of statements left to move.  `Statements'
do not include blank, comment, or continuation lines."
  (interactive "p") ; numeric prefix arg
  (if (< count 0) (py-previous-statement (- count))
    (beginning-of-line)
    (let ( start )
      (while (and
          (setq start (point)) ; always true -- side effect
          (> count 0)
          (py-goto-statement-below))
    (setq count (1- count)))
      (if (> count 0) (goto-char start)))
    count))

(defun py-goto-block-up (&optional nomark)
  "Move up to start of current block.
Go to the statement that starts the smallest enclosing block; roughly
speaking, this will be the closest preceding statement that ends with a
colon and is indented less than the statement you started on.  If
successful, also sets the mark to the starting point.

`\\[py-mark-block]' can be used afterward to mark the whole code block, if desired.

If called from a program, the mark will not be set if optional argument
NOMARK is not nil."
  (interactive)
  (let ( (start (point))
     (found nil)
     initial-indent)
    (py-goto-initial-line)
    ;; if on blank or non-indenting comment line, use the preceding stmt
    (if (looking-at "[ \t]*\\($\\|#[^ \t\n]\\)")
    (progn
      (py-goto-statement-at-or-above)
      (setq found (looking-at py-colon-line-re))))
    ;; search back for colon line indented less
    (setq initial-indent (current-indentation))
    (if (zerop initial-indent)
    ;; force fast exit
    (goto-char (point-min)))
    (while (not (or found (bobp)))
      (setq found
        (and
         (re-search-backward ":[ \t]*\\($\\|[#\\]\\)" nil 'move)
         (progn
           (py-goto-initial-line)
           (and
        (< (current-indentation) initial-indent)
        (looking-at py-colon-line-re))))))
    (if found
    (progn
      (or nomark (push-mark start))
      (back-to-indentation))
      (goto-char start)
      (error "Enclosing block not found"))))

;;; Functions for marking regions

(defun py-mark-block ()
  "Mark following block of lines.
Easier to use than explain.  It sets the region to an `interesting'
block of succeeding lines.  If point is on a blank line, it goes down to
the next non-blank line.  That will be the start of the region.  The end
of the region depends on the kind of line at the start:

 - If a comment, the region will include all succeeding comment lines up
   to (but not including) the next non-comment line (if any).

 - If a code line that opens a new block, the region will include all
   succeeding lines up to (but not including) the next code statement
   (if any) that's indented no more than the starting line, except that
   trailing blank and comment lines are excluded.  E.g., if the starting
   line is a `def' statement, the region will be set to the full
   function definition, but without any trailing `noise' lines.

 - Else the region will include all succeeding lines up to (but not
   including) the next blank line, or code or indenting-comment line
   indented strictly less than the starting line.  Trailing indenting
   comment lines are included in this case, but not trailing blank
   lines.

A msg identifying the location of the mark is displayed in the echo
area; or do `\\[exchange-point-and-mark]' to flip down to the end."
  (interactive)
  (py-goto-initial-line)
  ;; skip over blank lines
  (while (and
      (looking-at "[ \t]*$")    ; while blank line
      (not (eobp)))            ; & somewhere to go
    (forward-line 1))
  (if (eobp)
      (error "Hit end of buffer without finding a non-blank stmt"))
  (let ( (initial-pos (point))
     (initial-indent (current-indentation))
     last-pos)            ; position of last stmt in region
    (cond
     ;; if comment line, suck up the following comment lines
     ((looking-at "[ \t]*#")
      (re-search-forward "^[ \t]*[^ \t#]" nil 'move) ; look for non-comment
      (re-search-backward "^[ \t]*#")    ; and back to last comment in block
      (setq last-pos (point)))
     ;; else if line opens a block, search for next stmt indented <=
     ((looking-at py-colon-line-re)
      (while (and
          (setq last-pos (point))    ; always true -- side effect
          (py-goto-statement-below)
          (> (current-indentation) initial-indent))
    nil))
     ;; else plain code line; stop at next blank line, or stmt or
     ;; indenting comment line indented <
     (t
      (while (and
          (setq last-pos (point))    ; always true -- side effect
          (or (py-goto-beyond-final-line) t)
          (not (looking-at "[ \t]*$")) ; stop at blank line
          (or
           (>= (current-indentation) initial-indent)
           (looking-at "[ \t]*#[^ \t\n]"))) ; ignore non-indenting #
    nil)))

    ;; skip to end of last stmt
    (goto-char last-pos)
    (py-goto-beyond-final-line)
    ;; set mark & display
    (push-mark (point) 'no-msg)

    (forward-line -1)
    (message "Mark set after: %s" (py-suck-up-leading-text))

    (goto-char initial-pos)))

(defun py-comment-region (start end &optional uncomment-p)
  "Comment out region of code; with prefix arg, uncomment region.
The lines from the line containing the start of the current region up
to (but not including) the line containing the end of the region are
commented out, by inserting the string py-block-comment-prefix at the
start of each line.  With a prefix arg, removes py-block-comment-prefix
from the start of each line instead."
  (interactive "*r\nP")   ; region; raw prefix arg
  (goto-char end)   (beginning-of-line) (setq end (point))
  (goto-char start) (beginning-of-line) (setq start (point))
  (let ( (prefix-len (length py-block-comment-prefix)) )
    (save-excursion
      (save-restriction
    (narrow-to-region start end)
    (while (not (eobp))
      (if uncomment-p
          (and (string= py-block-comment-prefix
                (buffer-substring
                 (point) (+ (point) prefix-len)))
           (delete-char prefix-len))
        (insert py-block-comment-prefix))
      (forward-line 1))))))

;;; Documentation functions

;; dump the long form of the mode blurb; does the usual doc escapes,
;; plus lines of the form ^[vc]:name$ to suck variable & command
;; docs out of the right places, along with the keys they're on &
;; current values
(defun py-dump-help-string (str)
  (with-output-to-temp-buffer "*Help*"
    (let ( kind
       funcname func funcdoc
       (start 0) mstart end
       keys )
      (while (string-match "^%\\([vc]\\):\\(.+\\)\n" str start)
    (setq mstart (match-beginning 0)  end (match-end 0)
          kind (substring str (match-beginning 1) (match-end 1))
          funcname (substring str (match-beginning 2) (match-end 2))
          func (car (read-from-string funcname)))
    (princ (substitute-command-keys (substring str start mstart)))
    (if (equal kind "c")
        (setq funcdoc (documentation func)
          keys (concat
            "Key(s): "
            (mapconcat 'key-description
                   (where-is-internal func py-mode-map)
                   ", ")))
      (setq funcdoc (substitute-command-keys
             (get func 'variable-documentation))
        keys (concat
              "Value: "
              (prin1-to-string (symbol-value func)))))
    (princ (format "\n-> %s:\t%s\t%s\n\n"
               (if (equal kind "c") "Command" "Variable")
               funcname keys))
    (princ funcdoc)
    (princ "\n")
    (setq start end))
      (princ (substitute-command-keys (substring str start))))
    (print-help-return-message)))

(defun py-describe-mode ()
  "Dump long form of Python-mode docs."
  (interactive)
  (py-dump-help-string "Major mode for editing Python files.
Knows about Python tokens, comments and continuation lines.
Paragraphs are separated by blank lines only.

Major sections below begin with the string `@'; specific function and
variable docs begin with `->'.

@EXECUTING PYTHON CODE

\\[py-execute-buffer]\tsends the entire buffer to the Python interpreter
\\[py-execute-region]\tsends the current region
\\[py-shell]\tstarts a Python interpreter window; this will be used by
\tsubsequent \\[py-execute-buffer] or \\[py-execute-region] commands
%c:py-execute-buffer
%c:py-execute-region
%c:py-shell

@VARIABLES

py-python-command\tshell command to invoke Python interpreter
py-indent-offset\tindentation increment
py-continuation-offset\textra indentation given to continuation lines
py-block-comment-prefix\tcomment string used by `\\[py-comment-region]'
py-beep-if-tab-change\tring the bell if tab-width is changed
%v:py-python-command
%v:py-indent-offset
%v:py-continuation-offset
%v:py-block-comment-prefix
%v:py-beep-if-tab-change

@KINDS OF LINES

Each physical line in the file is either a `continuation line' (the
preceding line ends with a backslash that's not part of a comment) or an
`initial line' (everything else).

An initial line is in turn a `blank line' (contains nothing except
possibly blanks or tabs), a `comment line' (leftmost non-blank character
is `#'), or a `code line' (everything else).

Comment Lines

Although all comment lines are treated alike by Python, Python mode
recognizes two kinds that act differently with respect to indentation.

An `indenting comment line' is a comment line with a blank, tab or
nothing after the initial `#'.  The indentation commands (see below)
treat these exactly as if they were code lines:  a line following an
indenting comment line will be indented like the comment line.  All
other comment lines (those with a non-whitespace character immediately
following the initial `#') are `non-indenting comment lines', and their
indentation is ignored by the indentation commands.

Indenting comment lines are by far the usual case, and should be used
whenever possible.  Non-indenting comment lines are useful in cases like
these:

\ta = b   # a very wordy single-line comment that ends up being
\t        #... continued onto another line

\tif a == b:
##\t\tprint 'panic!' # old code we've `commented out'
\t\treturn a

Since the `#...' and `##' comment lines have a non-whitespace character
following the initial `#', Python mode ignores them when computing the
proper indentation for the next line.

Continuation Lines and Statements

The Python-mode commands generally work on statements instead of on
individual lines, where a `statement' is a comment or blank line, or a
code line and all of its following continuation lines (if any)
considered as a single logical unit.  The commands in this mode
generally (when it makes sense) automatically move to the start of the
statement containing point, even if point happens to be in the middle of
some continuation line.

A Bad Idea

Always put something on the initial line of a multi-line statement
besides the backslash!  E.g., don't do this:

\t\\
\ta = b # what's the indentation of this stmt?

While that's legal Python, it's silly & would be very expensive for
Python mode to handle correctly.

@INDENTATION

Primarily for entering new code:
\t\\[indent-for-tab-command]\t indent line appropriately
\t\\[py-newline-and-indent]\t insert newline, then indent
\t\\[py-delete-char]\t reduce indentation, or delete single character

Primarily for reindenting existing code:
\t\\[py-indent-region]\t reindent region to match its context
\t\\[py-shift-region-left]\t shift region left by py-indent-offset
\t\\[py-shift-region-right]\t shift region right by py-indent-offset

Unlike most programming languages, Python uses indentation, and only
indentation, to specify block structure.  Hence the indentation supplied
automatically by Python-mode is just an educated guess:  only you know
the block structure you intend, so only you can supply correct
indentation.

The \\[indent-for-tab-command] and \\[py-newline-and-indent] keys try to suggest plausible indentation, based on
the indentation of preceding statements.  E.g., assuming
py-indent-offset is 4, after you enter
\tif a > 0: \\[py-newline-and-indent]
the cursor will be moved to the position of the `x':
\tif a > 0:
\t    x
If you then enter `c = d' \\[py-newline-and-indent], the cursor will move
to
\tif a > 0:
\t    c = d
\t    x
Python-mode cannot know whether that's what you intended, or whether
\tif a > 0:
\t    c = d
\tx
was your intent.  In general, Python-mode either reproduces the
indentation of the (closest code or indenting-comment) preceding
statement, or adds an extra py-indent-offset blanks if the preceding
statement has `:' as its last significant (non-whitespace and non-
comment) character.  If the suggested indentation is too much, use
\\[py-delete-char] to reduce it.

Warning:  indent-region should not normally be used!  It calls \\[indent-for-tab-command]
repeatedly, and as explained above, \\[indent-for-tab-command] can't guess the block
structure you intend.
%c:indent-for-tab-command
%c:py-newline-and-indent
%c:py-delete-char

The remaining `indent' functions apply to a region of Python code.  They
assume the block structure (equals indentation, in Python) of the region
is correct, and alter the indentation in various ways while preserving
the block structure:
%c:py-indent-region
%c:py-shift-region-left
%c:py-shift-region-right

@MARKING & MANIPULATING REGIONS OF CODE

\\[py-mark-block]\t mark block of lines
\\[py-comment-region]\t comment out region of code
\\[universal-argument] \\[py-comment-region]\t uncomment region of code
%c:py-mark-block
%c:py-comment-region

@MOVING POINT

\\[py-previous-statement]\t move to statement preceding point
\\[py-next-statement]\t move to statement following point
\\[py-goto-block-up]\t move up to start of current block

The first two move to one statement beyond the statement that contains
point.  A numeric prefix argument tells them to move that many
statements instead.  Blank lines, comment lines, and continuation lines
do not count as `statements' for these commands.  So, e.g., you can go
to the first code statement in a file by entering
\t\\[beginning-of-buffer]\t to move to the top of the file
\t\\[py-next-statement]\t to skip over initial comments and blank lines
Or do `\\[py-previous-statement]' with a huge prefix argument.
%c:py-previous-statement
%c:py-next-statement
%c:py-goto-block-up

@LITTLE-KNOWN EMACS COMMANDS PARTICULARLY USEFUL IN PYTHON MODE

`\\[indent-new-comment-line]' is handy for entering a multi-line comment.

`\\[set-selective-display]' with a `small' prefix arg is ideally suited for viewing
the overall class and def structure of a module.

`\\[indent-relative]' is handy for creating odd indentation.

@OTHER EMACS HINTS

If you don't like the default value of a variable, change its value to
whatever you do like by putting a `setq' line in your .emacs file.
E.g., to set the indentation increment to 4, put this line in your
.emacs:
\t(setq  py-indent-offset  4)
To see the value of a variable, do `\\[describe-variable]' and enter the variable
name at the prompt.

Entering Python mode calls with no arguments the value of the variable
`py-mode-hook', if that value exists and is not nil; see the `Hooks'
section of the Elisp manual for details.

Obscure:  When python-mode is first loaded, it looks for all bindings
to newline-and-indent in the global keymap, and shadows them with
local bindings to py-newline-and-indent."))

;;; Helper functions

;; go to initial line of current statement; usually this is the
;; line we're on, but if we're on the 2nd or following lines of a
;; continuation block, we need to go up to the first line of the block
(defun py-goto-initial-line ()
  (while (py-continuation-line-p)
    (forward-line -1))
  (beginning-of-line))

;; go to point right beyond final line of current statement; usually
;; this is the start of the next line, but if this is a multi-line
;; statement we need to skip over the continuation lines
(defun py-goto-beyond-final-line ()
  (forward-line 1)
  (while (and (py-continuation-line-p)
          (not (eobp)))
    (forward-line 1)))

;; t iff on continuation line == preceding line ends with backslash
;; that's not in a comment
(defun py-continuation-line-p ()
  (save-excursion
    (beginning-of-line)
    (and
     ;; use a cheap test first to avoid the regexp if possible
     ;; use 'eq' because char-after may return nil
     (eq (char-after (- (point) 2)) ?\\ )
     (progn
       (forward-line -1) ; since eq test passed, there is a line above
       (looking-at py-continued-re)))))

;; go to start of first statement (not blank or comment or continuation
;; line) at or preceding point
;; returns t if there is one, else nil
(defun py-goto-statement-at-or-above ()
  (py-goto-initial-line)
  (if (looking-at py-blank-or-comment-re)
    ;; skip back over blank & comment lines
    ;; note:  will skip a blank or comment line that happens to be
    ;; a continuation line too
    (if (re-search-backward "^[ \t]*[^ \t#\n]" nil t)
        (progn (py-goto-initial-line) t)
      nil)
    t))

;; go to start of first statement (not blank or comment or continuation
;; line) following the statement containing point
;; returns t if there is one, else nil
(defun py-goto-statement-below ()
  (beginning-of-line)
  (let ( (start (point)) )
    (py-goto-beyond-final-line)
    (while (and
        (looking-at py-blank-or-comment-re)
        (not (eobp)))
      (forward-line 1))
    (if (eobp)
    (progn (goto-char start) nil)
      t)))

;; return string in buffer from start of indentation to end of line;
;; prefix "..." if leading whitespace was skipped
(defun py-suck-up-leading-text ()
  (save-excursion
    (back-to-indentation)
    (concat
     (if (bolp) "" "...")
     (buffer-substring (point) (progn (end-of-line) (point))))))

;; To do:
;; - add a newline when executing buffer ending in partial line
;; - suppress prompts when executing regions
;; - switch back to previous buffer when starting shell
;; - support for ptags

>>> END OF MSG










Received: by charon.cwi.nl with SMTP; Wed, 19 Feb 1992 11:12:55 +0100
Received: by schelvis.cwi.nl with SMTP; Wed, 19 Feb 1992 10:12:54 GMT
Message-Id: <[e-mail]>
To: Tim Peters <[e-mail]>
Cc: [e-mail]
Subject: Re: (Emacs) Python mode, version 1.01
In-Reply-To: Message by Tim Peters <[e-mail]> ,
         Tue, 18 Feb 92 23:25:41 EST , <[e-mail]>
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone](home)
X-Last-Band-Seen: Henry Rollins Band (Paradiso, 17-2)
X-Mini-Review: Great!
Date: Wed, 19 Feb 1992 11:12:53 +0100
From: Jack Jansen <[e-mail]>

Tim,
if you're looking for more things to do to the python mode (grin:-):
Guido and myself are having eternal battels about indent level: he
uses 8 and I use 4. Needless to say, neither of us will give up, but I
often edit code by him (and the other way around). I find that I keep
using set-variable to change the indent, so I wonder wether it would
be possible to have a command that more-or-less automatically guesses
the indent of the current file and sets py-indent-offset accordingly...
--
Jack Jansen        | In Holland things are serious, but never hopeless.
[e-mail] | In Ireland things are hopeless, but never serious.
uunet!cwi.nl!jack   G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Received: by charon.cwi.nl with SMTP; Thu, 20 Feb 1992 07:32:36 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA29378; Thu, 20 Feb 92 01:32:30 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 013137.28691; Thu, 20 Feb 1992 01:31:37 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA05983; Thu, 20 Feb 92 01:20:29 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA21214; Thu, 20 Feb 92 01:20:28 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: (Emacs) Python mode, version 1.02
Cc: [e-mail]
Date: Thu, 20 Feb 92 01:20:27 EST
From: Tim Peters <[e-mail]>

>  [jack jansen]
>  if you're looking for more things to do to the python mode (grin:-):

Yes, actually -- of the spare time I've been able to make for Python
lately, I've spent 95% of it indenting Python instead of actually using
it <grin/sigh>.  Seriously, I can use all the input from the trenches I
can get.

>  Guido and myself are having eternal battles about indent level: he
>  uses 8 and I use 4.  Needless to say, neither of us will give up,

Well, of course *you* shouldn't give up, because you're right <grin>.

>  I often edit code by him (and the other way around). I find that I keep
>  using set-variable to change the indent, so I wonder wether it would
>  be possible to have a command that more-or-less automatically guesses
>  the indent of the current file and sets py-indent-offset accordingly...

A patch to change python-mode.el from version 1.01 to 1.02 is attached
below.  The new `C-c :' command should (I think) be close to what you
want.  Just hit `C-c :'; if it doesn't do what you wanted, read the docs
& try again.

Note that, by default, it makes py-indent-offset local to the buffer:
that way you can have Guido's code in one buffer, yours in another, and
when moving stuff between them `C-c TAB' will magically reindent
correctly for the buffer the stuff ends up in.  `C-c C-h m' has also
been changed to show both the local and the global values of a variable
(when two versions exist).

For those feeling nervous, the easiest way to use 'patch' is to

1) Read this whole mail msg into a file, say some_file.

2) Go to the directory that contains python-mode.el, and enter

    patch < some_file

   That will rename the original python-mode.el to python-mode.el.orig,
   and upgrade python-mode.el to version 1.02.

a-fellow-indenter-by-4's-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

Change log:

Thu Feb 20 00:13:34 1992  tim
version 1.02
added hint on entering multiple CTRL keys
added back-to-indentation to the "obscure Emacs cmds" section
added 'indentation' to the short blurbs saying what py-mode knows about
tossed progn in py-continuation-line-p (a tad faster)
    ditto in py-goto-block-up
changed `x' to `_' in the "why indentation is up to you" blurb
    for clarity (sez guido; i agree)
several changes to py-dump-help-string
    replaced read-from-string by `intern'
    ditto (princ "\n") -> (terpri)
    renamed 'kind' -> 'funckind'
    signal error if funckind unknown
    display both local & global vrbl values (if appropriate)
added new function py-guess-indent-offset (a la jack jansen)
    bound to `C-c :'; updated docs

Patch:

*** python-mode.el    Wed Feb 19 23:21:58 1992
--- python-mode.102.el    Wed Feb 19 23:34:05 1992
***************
*** 1,4 ****
! ;;; Major mode for editing Python programs, version 1.01
  ;; by: Michael A. Guravage
  ;;     Guido van Rossum <[e-mail]>
  ;;     Tim Peters <[e-mail]>
--- 1,4 ----
! ;;; Major mode for editing Python programs, version 1.02
  ;; by: Michael A. Guravage
  ;;     Guido van Rossum <[e-mail]>
  ;;     Tim Peters <[e-mail]>
***************
*** 28,34 ****
    "*Shell command used to start Python interpreter.")

  (defvar py-indent-offset 8        ; argue with Guido <grin>
!   "*Indentation increment.")

  (defvar py-continuation-offset 2
    "*Indentation (in addition to py-indent-offset) for continued lines.
--- 28,36 ----
    "*Shell command used to start Python interpreter.")

  (defvar py-indent-offset 8        ; argue with Guido <grin>
!   "*Indentation increment.
! Note that `\\[py-guess-indent-offset]' can usually guess a good value when you're
! editing someone else's Python code.")

  (defvar py-continuation-offset 2
    "*Indentation (in addition to py-indent-offset) for continued lines.
***************
*** 73,78 ****
--- 75,81 ----
    (define-key py-mode-map "\C-c!"    'py-shell)
    (define-key py-mode-map "\177"    'py-delete-char)
    (define-key py-mode-map "\n"        'py-newline-and-indent)
+   (define-key py-mode-map "\C-c:"    'py-guess-indent-offset)
    (define-key py-mode-map "\C-c\t"    'py-indent-region)
    (define-key py-mode-map "\C-c<"    'py-shift-region-left)
    (define-key py-mode-map "\C-c>"    'py-shift-region-right)
***************
*** 140,146 ****
  (defun python-mode ()
    "Major mode for editing Python files.
  Do `\\[py-describe-mode]' for detailed documentation.
! Knows about Python tokens, comments and continuation lines.
  Paragraphs are separated by blank lines only.

  COMMANDS
--- 143,149 ----
  (defun python-mode ()
    "Major mode for editing Python files.
  Do `\\[py-describe-mode]' for detailed documentation.
! Knows about Python indentation, tokens, comments and continuation lines.
  Paragraphs are separated by blank lines only.

  COMMANDS
***************
*** 324,329 ****
--- 327,387 ----
         (+ (current-indentation) py-indent-offset)
       (current-indentation))))))

+ (defun py-guess-indent-offset (&optional global)
+   "Guess a good value for, and change, py-indent-offset.
+ By default (without a prefix arg), makes a buffer-local copy of
+ py-indent-offset with the new value.  This will not affect any other
+ Python buffers.  With a prefix arg, changes the global value of
+ py-indent-offset.  This affects all Python buffers (that don't have
+ their own buffer-local copy), both those currently existing and those
+ created later in the Emacs session.
+
+ Some people use a different value for py-indent-offset than you use.
+ There's no excuse for such foolishness, but sometimes you have to deal
+ with their ugly code anyway.  This function examines the file and sets
+ py-indent-offset to what it thinks it was when they created the mess.
+
+ Specifically, it searches forward from the statement containing point,
+ looking for a line that opens a block of code.  py-indent-offset is set
+ to the difference in indentation between that line and the Python
+ statement following it.  If the search doesn't succeed going forward,
+ it's tried again going backward."
+   (interactive "P")            ; raw prefix arg
+   (let ( new-value
+      (start (point))
+      (found nil)
+      colon-indent)
+     (py-goto-initial-line)
+     (while (not (or found (eobp)))
+       (setq found
+         (and
+          (re-search-forward ":[ \t]*\\($\\|[#\\]\\)" nil 'move)
+          (or (py-goto-initial-line) t) ; always true -- side effect
+          (looking-at py-colon-line-re))))
+     (if found
+     ()
+       (goto-char start)
+       (py-goto-initial-line)
+       (while (not (or found (bobp)))
+     (setq found
+           (and
+            (re-search-backward ":[ \t]*\\($\\|[#\\]\\)" nil 'move)
+            (or (py-goto-initial-line) t) ; always true -- side effect
+            (looking-at py-colon-line-re)))))
+     (setq colon-indent (current-indentation)
+       found (and found (zerop (py-next-statement 1)))
+       new-value (- (current-indentation) colon-indent))
+     (goto-char start)
+     (if found
+     (progn
+       (funcall (if global 'kill-local-variable 'make-local-variable)
+            'py-indent-offset)
+       (setq py-indent-offset new-value)
+       (message "%s value of py-indent-offset set to %d"
+            (if global "Global" "Local")
+            py-indent-offset))
+       (error "Sorry, couldn't guess a value for py-indent-offset"))))
+
  (defun py-shift-region (start end count)
    (save-excursion
      (goto-char end)   (beginning-of-line) (setq end (point))
***************
*** 500,510 ****
        (setq found
          (and
           (re-search-backward ":[ \t]*\\($\\|[#\\]\\)" nil 'move)
!          (progn
!            (py-goto-initial-line)
!            (and
!         (< (current-indentation) initial-indent)
!         (looking-at py-colon-line-re))))))
      (if found
      (progn
        (or nomark (push-mark start))
--- 558,566 ----
        (setq found
          (and
           (re-search-backward ":[ \t]*\\($\\|[#\\]\\)" nil 'move)
!          (or (py-goto-initial-line) t) ; always true -- side effect
!          (< (current-indentation) initial-indent)
!          (looking-at py-colon-line-re))))
      (if found
      (progn
        (or nomark (push-mark start))
***************
*** 618,650 ****
  ;; current values
  (defun py-dump-help-string (str)
    (with-output-to-temp-buffer "*Help*"
!     (let ( kind
!        funcname func funcdoc
         (start 0) mstart end
         keys )
        (while (string-match "^%\\([vc]\\):\\(.+\\)\n" str start)
      (setq mstart (match-beginning 0)  end (match-end 0)
!           kind (substring str (match-beginning 1) (match-end 1))
            funcname (substring str (match-beginning 2) (match-end 2))
!           func (car (read-from-string funcname)))
      (princ (substitute-command-keys (substring str start mstart)))
!     (if (equal kind "c")
!         (setq funcdoc (documentation func)
!           keys (concat
!             "Key(s): "
!             (mapconcat 'key-description
!                    (where-is-internal func py-mode-map)
!                    ", ")))
!       (setq funcdoc (substitute-command-keys
!              (get func 'variable-documentation))
!         keys (concat
!               "Value: "
!               (prin1-to-string (symbol-value func)))))
      (princ (format "\n-> %s:\t%s\t%s\n\n"
!                (if (equal kind "c") "Command" "Variable")
                 funcname keys))
      (princ funcdoc)
!     (princ "\n")
      (setq start end))
        (princ (substitute-command-keys (substring str start))))
      (print-help-return-message)))
--- 674,716 ----
  ;; current values
  (defun py-dump-help-string (str)
    (with-output-to-temp-buffer "*Help*"
!     (let ( (locals (buffer-local-variables))
!        funckind funcname func funcdoc
         (start 0) mstart end
         keys )
        (while (string-match "^%\\([vc]\\):\\(.+\\)\n" str start)
      (setq mstart (match-beginning 0)  end (match-end 0)
!           funckind (substring str (match-beginning 1) (match-end 1))
            funcname (substring str (match-beginning 2) (match-end 2))
!           func (intern funcname))
      (princ (substitute-command-keys (substring str start mstart)))
!     (cond
!      ( (equal funckind "c")        ; command
!        (setq funcdoc (documentation func)
!          keys (concat
!                "Key(s): "
!                (mapconcat 'key-description
!                   (where-is-internal func py-mode-map)
!                   ", "))))
!      ( (equal funckind "v")        ; variable
!        (setq funcdoc (substitute-command-keys
!               (get func 'variable-documentation))
!          keys (if (assq func locals)
!               (concat
!                "Local/Global values: "
!                (prin1-to-string (symbol-value func))
!                " / "
!                (prin1-to-string (default-value func)))
!             (concat
!              "Value: "
!              (prin1-to-string (symbol-value func))))))
!      ( t                ; unexpected
!        (error "Error in py-dump-help-string, tag `%s'" funckind)))
      (princ (format "\n-> %s:\t%s\t%s\n\n"
!                (if (equal funckind "c") "Command" "Variable")
                 funcname keys))
      (princ funcdoc)
!     (terpri)
      (setq start end))
        (princ (substitute-command-keys (substring str start))))
      (print-help-return-message)))
***************
*** 653,659 ****
    "Dump long form of Python-mode docs."
    (interactive)
    (py-dump-help-string "Major mode for editing Python files.
! Knows about Python tokens, comments and continuation lines.
  Paragraphs are separated by blank lines only.

  Major sections below begin with the string `@'; specific function and
--- 719,725 ----
    "Dump long form of Python-mode docs."
    (interactive)
    (py-dump-help-string "Major mode for editing Python files.
! Knows about Python indentation, tokens, comments and continuation lines.
  Paragraphs are separated by blank lines only.

  Major sections below begin with the string `@'; specific function and
***************
*** 749,754 ****
--- 815,823 ----
  \t\\[py-delete-char]\t reduce indentation, or delete single character

  Primarily for reindenting existing code:
+ \t\\[py-guess-indent-offset]\t guess py-indent-offset from file content; change locally
+ \t\\[universal-argument] \\[py-guess-indent-offset]\t ditto, but change globally
+
  \t\\[py-indent-region]\t reindent region to match its context
  \t\\[py-shift-region-left]\t shift region left by py-indent-offset
  \t\\[py-shift-region-right]\t shift region right by py-indent-offset
***************
*** 763,780 ****
  the indentation of preceding statements.  E.g., assuming
  py-indent-offset is 4, after you enter
  \tif a > 0: \\[py-newline-and-indent]
! the cursor will be moved to the position of the `x':
  \tif a > 0:
! \t    x
  If you then enter `c = d' \\[py-newline-and-indent], the cursor will move
  to
  \tif a > 0:
  \t    c = d
! \t    x
  Python-mode cannot know whether that's what you intended, or whether
  \tif a > 0:
  \t    c = d
! \tx
  was your intent.  In general, Python-mode either reproduces the
  indentation of the (closest code or indenting-comment) preceding
  statement, or adds an extra py-indent-offset blanks if the preceding
--- 832,851 ----
  the indentation of preceding statements.  E.g., assuming
  py-indent-offset is 4, after you enter
  \tif a > 0: \\[py-newline-and-indent]
! the cursor will be moved to the position of the `_' (_ is not a
! character in the file, it's just used here to indicate the location of
! the cursor):
  \tif a > 0:
! \t    _
  If you then enter `c = d' \\[py-newline-and-indent], the cursor will move
  to
  \tif a > 0:
  \t    c = d
! \t    _
  Python-mode cannot know whether that's what you intended, or whether
  \tif a > 0:
  \t    c = d
! \t_
  was your intent.  In general, Python-mode either reproduces the
  indentation of the (closest code or indenting-comment) preceding
  statement, or adds an extra py-indent-offset blanks if the preceding
***************
*** 789,794 ****
--- 860,870 ----
  %c:py-newline-and-indent
  %c:py-delete-char

+
+ The next function may be handy when editing code you didn't write:
+ %c:py-guess-indent-offset
+
+
  The remaining `indent' functions apply to a region of Python code.  They
  assume the block structure (equals indentation, in Python) of the region
  is correct, and alter the indentation in various ways while preserving
***************
*** 827,835 ****

  `\\[indent-new-comment-line]' is handy for entering a multi-line comment.

! `\\[set-selective-display]' with a `small' prefix arg is ideally suited for viewing
! the overall class and def structure of a module.

  `\\[indent-relative]' is handy for creating odd indentation.

  @OTHER EMACS HINTS
--- 903,913 ----

  `\\[indent-new-comment-line]' is handy for entering a multi-line comment.

! `\\[set-selective-display]' with a `small' prefix arg is ideally suited for viewing the
! overall class and def structure of a module.

+ `\\[back-to-indentation]' moves point to a line's first non-blank character.
+
  `\\[indent-relative]' is handy for creating odd indentation.

  @OTHER EMACS HINTS
***************
*** 842,847 ****
--- 920,931 ----
  To see the value of a variable, do `\\[describe-variable]' and enter the variable
  name at the prompt.

+ When entering a key sequence like `C-c C-n', it is not necessary to
+ release the CONTROL key after doing the `C-c' part -- it suffices to
+ press the CONTROL key, press and release `c' (while still holding down
+ CONTROL), press and release `n' (while still holding down CONTROL), &
+ then release CONTROL.
+
  Entering Python mode calls with no arguments the value of the variable
  `py-mode-hook', if that value exists and is not nil; see the `Hooks'
  section of the Elisp manual for details.
***************
*** 878,886 ****
       ;; use a cheap test first to avoid the regexp if possible
       ;; use 'eq' because char-after may return nil
       (eq (char-after (- (point) 2)) ?\\ )
!      (progn
!        (forward-line -1) ; since eq test passed, there is a line above
!        (looking-at py-continued-re)))))

  ;; go to start of first statement (not blank or comment or continuation
  ;; line) at or preceding point
--- 962,970 ----
       ;; use a cheap test first to avoid the regexp if possible
       ;; use 'eq' because char-after may return nil
       (eq (char-after (- (point) 2)) ?\\ )
!      ;; make sure; since eq test passed, there is a preceding line
!      (forward-line -1) ; always true -- side effect
!      (looking-at py-continued-re))))

  ;; go to start of first statement (not blank or comment or continuation
  ;; line) at or preceding point

>>> END OF MSG










Received: by charon.cwi.nl with SMTP; Thu, 20 Feb 1992 20:03:09 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA25663; Thu, 20 Feb 92 14:03:11 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 140201.203; Thu, 20 Feb 1992 14:02:01 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA11063; Thu, 20 Feb 92 14:01:10 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA18285; Thu, 20 Feb 92 14:01:08 EST
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: (Emacs) Python mode, version 1.02.01
Date: Thu, 20 Feb 92 14:01:07 EST
From: Tim Peters <[e-mail]>

The new py-guess-indent-offset (C-c :) could get into an infinite loop
in the presence of some unusual comment or continuation lines.  The
patch below fixes that.

send-me-a-bill-for-the-cycles-you-wasted<grin>-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

Change log:

Thu Feb 20 13:20:59 1992  tim
version 1.02.01
fixed infinite loop in py-guess-indent-offset
    have to restart re-search-forward where it left off in case
        colon found at end of, e.g., a comment line

Patch:

*** python-mode.el    Thu Feb 20 13:15:17 1992
--- python-mode.10201.el    Thu Feb 20 13:39:45 1992
***************
*** 1,4 ****
! ;;; Major mode for editing Python programs, version 1.02
  ;; by: Michael A. Guravage
  ;;     Guido van Rossum <[e-mail]>
  ;;     Tim Peters <[e-mail]>
--- 1,4 ----
! ;;; Major mode for editing Python programs, version 1.02.01
  ;; by: Michael A. Guravage
  ;;     Guido van Rossum <[e-mail]>
  ;;     Tim Peters <[e-mail]>
***************
*** 349,363 ****
    (interactive "P")            ; raw prefix arg
    (let ( new-value
       (start (point))
       (found nil)
       colon-indent)
      (py-goto-initial-line)
      (while (not (or found (eobp)))
!       (setq found
!         (and
!          (re-search-forward ":[ \t]*\\($\\|[#\\]\\)" nil 'move)
!          (or (py-goto-initial-line) t) ; always true -- side effect
!          (looking-at py-colon-line-re))))
      (if found
      ()
        (goto-char start)
--- 349,366 ----
    (interactive "P")            ; raw prefix arg
    (let ( new-value
       (start (point))
+      restart
       (found nil)
       colon-indent)
      (py-goto-initial-line)
      (while (not (or found (eobp)))
!       (if (re-search-forward ":[ \t]*\\($\\|[#\\]\\)" nil 'move)
!       (progn
!         (setq restart (point))
!         (py-goto-initial-line)
!         (if (looking-at py-colon-line-re)
!         (setq found t)
!           (goto-char restart)))))
      (if found
      ()
        (goto-char start)

>>> END OF MSG










Received: by charon.cwi.nl with SMTP; Sat, 22 Feb 1992 06:02:00 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01631; Sat, 22 Feb 92 00:02:05 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 000121.12599; Sat, 22 Feb 1992 00:01:21 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA02584; Fri, 21 Feb 92 23:31:20 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA16956; Fri, 21 Feb 92 23:31:17 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: (Emacs python-mode) Anyone use `C-c |' or `C-c !'?
Cc: [e-mail]
Date: Fri, 21 Feb 92 23:31:17 EST
From: Tim Peters <[e-mail]>

I don't have any major problems with py-execute-region or py-execute-
buffer so long as a Python process doesn't exist.  But if a Python
process does exist, they don't work for me worth beans if there's more
than one newline in the region being sent.  Does anyone else have this
problem?  If so, does anyone know why it happens?  If so, does anyone
know how to fix it?

Example:

1) Do `C-c !' to start up a Python process.  When I do this, I see a new
   "*Python*" buffer that looks like:

Python 0.9.4 alpha (>= Dec 24 1991).
Copyright 1990, 1991, 1992 Stichting Mathematisch Centrum, Amsterdam
>>>

2) In a .py file, set the region around the following three lines:

a = 9
b = 12
print a

3) Do `C-c |'.  When I do this, I see the Python process buffer change
   to:

Python 0.9.4 alpha (>= Dec 24 1991).
Copyright 1990, 1991, 1992 Stichting Mathematisch Centrum, Amsterdam
>>> >>>

   I.e., there's just one additional prompt, and typing stuff in
   confirms that "a = 9" is the only line Python actually saw.

In other words, Python only sees (or acts on) the stuff up thru the
first newline.  This is *not* due to some buffer overflowing in our
system:  I can send a Python statement containing many thousands of
characters, and it works fine so long as it's the only statement.  It's
not really a problem with multiple statements, either -- slamming
multiple statements into a line works fine so long as they're separated
by semicolons.  But use newlines instead of semicolons, & only the first
statement "works".

I don't think our Emacs is busted, either.  E.g., after

   (make-shell "Cat" "cat")

I can process-send-string strings with multiple newlines to the "Cat"
process and they all get echo'ed.  Ditto to shells, etc.

In fact, everything I've tried sez that the problem is unique to running
an interactive Python process.  Guido, does this make any sense to you?
E.g., in interactive mode, does Python perhaps just ignore stuff after
the first newline (between printing prompts, that is ...).

One thing that does work:  breaking the input into lines, & sending them
to the Python process one at a time, waiting for a prompt after each.
That's easy enough to do in Elisp, but shudder <grin>.


An entirely different (i.e., not directly to do with py-mode) problem:

def fac(n):
    if n <= 2: return n
    return n * fac(n-1)
fac(6)

That works fine if run as a Python script.  However, if typed in to an
interactive Python, the "fac(6)" triggers

fac(6)
   ^
Unhandled exception: SyntaxError: invalid syntax

apparently because in interactive mode Python wants to see an empty line
terminate the def.  A consequence is that py-execute-region won't always
work as expected (when a Python process is active) even if the newline
mystery is cleared up.  This one clearly appears to be a flaw (or
feature <ahem>) of Python itself.  Agreed?

at-least-i'm-learning-a-lot-about-elisp<grin>-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










Received: by charon.cwi.nl with SMTP; Sat, 22 Feb 1992 06:32:32 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA01355; Sat, 22 Feb 92 00:32:13 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 003125.16860; Sat, 22 Feb 1992 00:31:25 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA03261; Sat, 22 Feb 92 00:04:45 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA17831; Sat, 22 Feb 92 00:04:44 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: (Emacs python-mode.el) Patch 1.02.01 -> 1.03
Date: Sat, 22 Feb 92 00:04:43 EST
From: Tim Peters <[e-mail]>

Almost all language modes set up bindings for these three keys:

    ESC C-a        move to start of current function
    ESC C-e        move to end of current function
    ESC C-h        wrap region around current function

The patch below (finally ...) does this for Python.  Two odd wrinkles
unique to Python:

1) "Current function" is ambiguous because it might reasonably be taken
   to mean "def" or "class".  By default, these keys look at the current
   def.  Give them a prefix arg (e.g., C-u first), and they look at the
   current class instead.

2) "Current def (or class)" is also ambiguous because def's and class's
   can nest in arbitrary ways to arbitrary depths in Python.  The
   ambiguity is resolved by always looking at the smallest def (or
   class) enclosing point (the first one "up the parse tree").

Future plans:

1) Just about out of both-possible-&-worth-more-than-they-cost ideas for
   additional editing functions in Python mode.  So speak up if there's
   something you'd really like that isn't here yet.

2) Intend to take a crack at making the "execute Python code" commands
   pleasant (or at least functional <grin>).

unbearably y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

Change log:

Thu Feb 20 22:55:39 1992  tim
version 1.03
finally added support for the conventional ESC C-{a,e,h}
    new helper py-go-up-tree-to-keyword
    new cmd beginning-of-python-def-or-class, bound to ESC C-a
    mew cmd end-of-python-def-or-class, bound to ESC C-e
    new cmd mark-python-def-or-class, bound to ESC C-h
    added optional arg JUST-MOVE to py-mark-block to help out
    updated docs

Patch:

*** python-mode.el    Fri Feb 21 23:35:59 1992
--- ../python-mode.el    Fri Feb 21 18:13:10 1992
***************
*** 1,4 ****
! ;;; Major mode for editing Python programs, version 1.02.01
  ;; by: Michael A. Guravage
  ;;     Guido van Rossum <[e-mail]>
  ;;     Tim Peters <[e-mail]>
--- 1,4 ----
! ;;; Major mode for editing Python programs, version 1.03
  ;; by: Michael A. Guravage
  ;;     Guido van Rossum <[e-mail]>
  ;;     Tim Peters <[e-mail]>
***************
*** 84,90 ****
    (define-key py-mode-map "\C-c\C-u"    'py-goto-block-up)
    (define-key py-mode-map "\C-c\C-b"    'py-mark-block)
    (define-key py-mode-map "\C-c#"    'py-comment-region)
!   (define-key py-mode-map "\C-c\C-hm"    'py-describe-mode))

  (defvar py-mode-syntax-table nil "Python mode syntax table")
  (if py-mode-syntax-table
--- 84,93 ----
    (define-key py-mode-map "\C-c\C-u"    'py-goto-block-up)
    (define-key py-mode-map "\C-c\C-b"    'py-mark-block)
    (define-key py-mode-map "\C-c#"    'py-comment-region)
!   (define-key py-mode-map "\C-c\C-hm"    'py-describe-mode)
!   (define-key py-mode-map "\e\C-a"    'beginning-of-python-def-or-class)
!   (define-key py-mode-map "\e\C-e"    'end-of-python-def-or-class)
!   (define-key py-mode-map "\e\C-h"    'mark-python-def-or-class))

  (defvar py-mode-syntax-table nil "Python mode syntax table")
  (if py-mode-syntax-table
***************
*** 571,579 ****
        (goto-char start)
        (error "Enclosing block not found"))))

  ;;; Functions for marking regions

! (defun py-mark-block ()
    "Mark following block of lines.
  Easier to use than explain.  It sets the region to an `interesting'
  block of succeeding lines.  If point is on a blank line, it goes down to
--- 574,635 ----
        (goto-char start)
        (error "Enclosing block not found"))))

+ (defun beginning-of-python-def-or-class (&optional class)
+   "Move point to start of def (or class, with prefix arg).
+
+ By default, looks for an appropriate `def'.  If you supply a prefix arg,
+ looks for a `class' instead.  The docs assume the `def' case; just
+ substitute `class' for `def' for the other case:
+
+ If point is on a blank or non-indenting comment line, moves back to
+ start of closest preceding code statement or indenting comment line.
+
+ If this is a `def' statement, leaves point at the start of it and
+ returns t.
+
+ Else searches for the smallest enclosing `def' block, leaves point at
+ the start of it and returns t (note that since class & def statements
+ can nest to arbitrary depths in Python, `smallest enclosing' doesn't
+ necessarily mean `closest preceding that's indented less'; this point is
+ subtle, and this remark is just to let you know that `smallest
+ enclosing' means what it says ...).
+
+ If no `def' statement can be found by those rules, leaves point at its
+ original location and signals an error.
+
+ If you just want to mark the def/class, see `\\[mark-python-def-or-class]'."
+   (interactive "P")            ; raw prefix arg
+   (let ( (start (point))
+      (which (if class "class" "def")))
+     (if (py-go-up-tree-to-keyword which)
+     t
+       (goto-char start)
+       (error "Enclosing %s not found" which))))
+
+ (defun end-of-python-def-or-class (&optional class)
+   "Move point beyond end of def (or class, with prefix arg) body.
+ See `\\[beginning-of-python-def-or-class]' docs for how the def (or class) is found.
+
+ Once the beginning statement is found, this function leaves point
+ immediately after the end of the body of this def (or class).  If it's a
+ one-liner (like `def onemore(n): return n+1'), point will move to the
+ start of the line immediately following the def or class statement.
+ Else point will move beyond the end of the body as defined in the docs
+ for `\\[py-mark-block]'.
+
+ If you just want to mark the def/class, see `\\[mark-python-def-or-class]'.
+
+ Returns the position of the start of the def or class."
+   (interactive "P")            ; raw prefix arg
+   (beginning-of-python-def-or-class class)
+   (prog1 (point)
+     (if (looking-at py-colon-line-re)
+     (py-mark-block 'just-move)
+       (py-goto-beyond-final-line))))
+
  ;;; Functions for marking regions

! (defun py-mark-block (&optional just-move)
    "Mark following block of lines.
  Easier to use than explain.  It sets the region to an `interesting'
  block of succeeding lines.  If point is on a blank line, it goes down to
***************
*** 597,603 ****
     lines.

  A msg identifying the location of the mark is displayed in the echo
! area; or do `\\[exchange-point-and-mark]' to flip down to the end."
    (interactive)
    (py-goto-initial-line)
    ;; skip over blank lines
--- 653,663 ----
     lines.

  A msg identifying the location of the mark is displayed in the echo
! area; or do `\\[exchange-point-and-mark]' to flip down to the end.
!
! If called from a program and optional argument JUST-MOVE is not nil,
! instead just moves to the end of the block, and does not set mark or
! display a msg."
    (interactive)
    (py-goto-initial-line)
    ;; skip over blank lines
***************
*** 638,651 ****
      ;; skip to end of last stmt
      (goto-char last-pos)
      (py-goto-beyond-final-line)
      ;; set mark & display
!     (push-mark (point) 'no-msg)

!     (forward-line -1)
!     (message "Mark set after: %s" (py-suck-up-leading-text))

!     (goto-char initial-pos)))

  (defun py-comment-region (start end &optional uncomment-p)
    "Comment out region of code; with prefix arg, uncomment region.
  The lines from the line containing the start of the current region up
--- 698,736 ----
      ;; skip to end of last stmt
      (goto-char last-pos)
      (py-goto-beyond-final-line)
+
      ;; set mark & display
!     (if just-move
!     ()                ; just return
!       (push-mark (point) 'no-msg)
!       (forward-line -1)
!       (message "Mark set after: %s" (py-suck-up-leading-text))
!       (goto-char initial-pos))))

! (defun mark-python-def-or-class (&optional class)
!   "Set region to body of def (or class, with prefix arg) enclosing point.
! Pushes the current mark, then point, on the mark ring (all language
! modes do this, but although it's handy it's never documented ...).

! See `\\[beginning-of-python-def-or-class]' docs for how the start of the def (or class, with
! prefix arg) is found.  This command leaves point in the same place,
! except that if the preceding line is blank, point is instead left at its
! start (mostly for compatibility with other language modes; it's handy if
! you get into the habit of leaving an empty line before def and class
! stmts).  The mark is set immediately after the end of the def (or class,
! with prefix arg), at the same place `\\[end-of-python-def-or-class]' leaves point."

+   (interactive "P")            ; raw prefix arg
+   (push-mark (point))
+   (let ( (start (end-of-python-def-or-class class)) )
+     (push-mark (point))
+     (goto-char (1- start))        ; end of preceding line or bobp
+     (if (= (current-indentation) (current-column))
+     (beginning-of-line)
+       ;; note that (forward-char 1) wouldn't work if def was at
+       ;; start of restriction
+       (goto-char start))))
+
  (defun py-comment-region (start end &optional uncomment-p)
    "Comment out region of code; with prefix arg, uncomment region.
  The lines from the line containing the start of the current region up
***************
*** 879,887 ****
--- 964,975 ----
  @MARKING & MANIPULATING REGIONS OF CODE

  \\[py-mark-block]\t mark block of lines
+ \\[mark-python-def-or-class]\t mark smallest enclosing def
+ \\[universal-argument] \\[mark-python-def-or-class]\t mark smallest enclosing class
  \\[py-comment-region]\t comment out region of code
  \\[universal-argument] \\[py-comment-region]\t uncomment region of code
  %c:py-mark-block
+ %c:mark-python-def-or-class
  %c:py-comment-region

  @MOVING POINT
***************
*** 889,894 ****
--- 977,986 ----
  \\[py-previous-statement]\t move to statement preceding point
  \\[py-next-statement]\t move to statement following point
  \\[py-goto-block-up]\t move up to start of current block
+ \\[beginning-of-python-def-or-class]\t move to start of def
+ \\[universal-argument] \\[beginning-of-python-def-or-class]\t move to start of class
+ \\[end-of-python-def-or-class]\t move to end of def
+ \\[universal-argument] \\[end-of-python-def-or-class]\t move to end of class

  The first two move to one statement beyond the statement that contains
  point.  A numeric prefix argument tells them to move that many
***************
*** 901,906 ****
--- 993,1000 ----
  %c:py-previous-statement
  %c:py-next-statement
  %c:py-goto-block-up
+ %c:beginning-of-python-def-or-class
+ %c:end-of-python-def-or-class

  @LITTLE-KNOWN EMACS COMMANDS PARTICULARLY USEFUL IN PYTHON MODE

***************
*** 997,1002 ****
--- 1091,1122 ----
      (if (eobp)
      (progn (goto-char start) nil)
        t)))
+
+ ;; go to start of statement, at or preceding point, starting with keyword
+ ;; KEY.  Skips blank lines and non-indenting comments upward first.  If
+ ;; that statement starts with KEY, done, else go back to first enclosing
+ ;; block starting with KEY.
+ ;; If successful, leaves point at the start of the KEY line & returns t.
+ ;; Else leaves point at an undefined place & returns nil.
+ (defun py-go-up-tree-to-keyword (key)
+   ;; skip blanks and non-indenting #
+   (py-goto-initial-line)
+   (while (and
+       (looking-at "[ \t]*\\($\\|#[^ \t\n]\\)")
+       (zerop (forward-line -1)))    ; go back
+     nil)
+   (py-goto-initial-line)
+   (let* ( (re (concat "[ \t]*" key "\\b"))
+       (case-fold-search nil)    ; let* so looking-at sees this
+       (found (looking-at re))
+       (dead nil))
+     (while (not (or found dead))
+       (condition-case nil        ; in case no enclosing block
+       (py-goto-block-up 'no-mark)
+     (error (setq dead t)))
+       (or dead (setq found (looking-at re))))
+     (beginning-of-line)
+     found))

  ;; return string in buffer from start of indentation to end of line;
  ;; prefix "..." if leading whitespace was skipped

>>> END OF MSG










Replied: Sun, 23 Feb 1992 16:07:52 +0100
Replied: "[e-mail] +inbox"
Received: by charon.cwi.nl with SMTP; Sun, 23 Feb 1992 04:00:54 +0100
Received: from uvacs.cs.virginia.edu by uvaarpa.Virginia.EDU id aa24092;
          22 Feb 92 22:00 EST
Received: from wilbury.cs.Virginia.EDU by uvacs.cs.Virginia.EDU (4.1/5.1.UVA)
    id AA26951; Sat, 22 Feb 92 21:59:34 EST
Posted-Date: Sat, 22 Feb 92 21:59:02 EST
Return-Path: <[e-mail]>
Received: by wilbury.cs.Virginia.EDU (4.1/SMI-2.0)
    id AA24837; Sat, 22 Feb 92 21:59:02 EST
Date: Sat, 22 Feb 92 21:59:02 EST
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: getfloatvalue()

I "fixed" a minor problem with Python and the C extensions. If you
attempt to read a float and it's actually an int, it doesn't get
converted; instead, it returns an error.

I've fixed it so that it automatically converts it for you.
Here is the new version of getfloatdouble(), located in floatobject.c:

double
getfloatvalue(op)
    object *op;
{
    if (!is_floatobject(op)) {
        if(!is_intobject(op)) {
        err_badarg();
        return -1;
        } else return (double)((intobject *)op) -> ob_ival;
    }
    else
        return ((floatobject *)op) -> ob_fval;
}

What the old version did was to see if the parameter being passed was
a float; if not, it returned an error. What I do now is before I
return, I see if it is an integer, and if it is, I convert it;
otherwise, there is still an error.

This could logically be extended to automatically convert strings,
etc.

Steve










Received: by charon.cwi.nl with SMTP; Sun, 23 Feb 1992 21:33:09 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA27087; Sun, 23 Feb 92 15:33:05 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 153120.28884; Sun, 23 Feb 1992 15:31:20 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA14100; Sun, 23 Feb 92 15:29:09 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA00729; Sun, 23 Feb 92 15:29:09 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: (Emacs python-mode) Anyone use `C-c |' or `C-c !'?
Date: Sun, 23 Feb 92 15:29:08 EST
From: Tim Peters <[e-mail]>

Hi!

About the readline library, too complicated for me -- I'm not a UNIX(tm)
hacker & God willing never will be <0.4 grin>.  I noted too with some
dismay that the "Input to Processes" section of the Elisp manual sez

>    Some operating systems have limited space for buffered input in a
> PTY.  On these systems, the subprocess will cease to read input
> correctly if you send an input line longer than the system can handle.
> You cannot avoid the problem by breaking the input into pieces and
> sending them separately, for the operating system will still have to
> put all the pieces together in the input buffer before it lets the
> subprocess read the line.  The only solution is to put the input in a
> temporary file, and send the process a brief command to read that
> file.

That one doesn't seem to be a problem on your or my systems, but
apparently it's an unsolvable problem on some other systems.  I find it
hard to imagine that *any* system is too lame to accept one (say) 80-
character line at a time, though!

>  >for i in 1,2,3:
>  >   print i
>  >a = b
>
>  The problem I see here is that if "a = b" were another for statement
>  ...

Point taken.  It would be unpleasant for the user (albeit in different
ways) whether you did or didn't display the first loop's output first --
can't win!

>  >for i in 1,2,3: print i
>  >a = b
>  >
>  >Python "should have" known that the for loop was a one-liner ...
>
>  It isn't, an 'else' clause can still follow on the next line!

Oops <turning red and hanging head in shame>.

>  >This [proceeding after an error] bothers me less than the preceding
>  >problems. ...
>
>  OK, it's a second order problem, but I still don't like it:

Me neither.

>  to me, "C-c |" means roughly "try this region".  I want it to fail
>  as a unit.

Ya, I share that view; it is subtly different from "send the region to
the process" in several respects, though.  I should change the docs to
make that clear.

>  >Question:  A while back you were considering adding a new Python function
>  >comparable to the csh "source" (or sh/ksh ".").
>
>  You can simulate ". filename" with "exec(open(filename, 'r').read())"
>  so after all I don't think you need a separate "source" or "execfile"
>  built-in function after all.

Last time this came up, I was concerned about the semantics of name-
resolution inside exec.  I.e., that exec'ing a string doesn't always do
the same thing as typing the string in.  In the context of code sent
over by py-mode, though, I *think* the local & global namespaces will
always be the same, so that it's not a problem (or may be a problem, but
so subtle that I can't think of how it might fail -- you?).

But you had another objection to the "execfile" approach, and I think it
still holds (we were talking about debuggers at the time):

> [you, in old mail from 13 Jan 92]
> Sure (there even is a trick to get at the caller's name spaces) but
> when reading from a file the debugger gets a fair chance of printing
> source code lines -- the string passed to exec or eval is not saved,
> but filenames are.

So here's file tempfile.py:

1
2
a = 2 +
3
print 'got here'

And here's an Emacs Python buffer in action:

>>> exec(open('tempfile.py','r').read())
Unhandled exception: SyntaxError: invalid syntax
Stack backtrace (innermost last):
  File "<stdin>", line 1
>>>

I believe this is an example of the problem you were talking about in
January, right?  The error msg isn't helpful.

If instead I'm editing tempfile.py and do a `C-c C-c', the current
version of py-execute-region (you don't have that yet) yields:

>>> ## working on region...
Parsing error: file <stdin>, line 4:
    a = 2 +
            ^
Unhandled exception: SyntaxError: invalid syntax
>>>

and an "Unexpected response from Python -- syntax error?" error msg is
dumped to the echo area.

The line number is off (because of the inserted "if 1:"), and the
leading tab on the offending line will be mysterious too, but even so
it's a much better error msg than we got by exec'ing the file.  So in
the absence of another approach, I'd rather take a chance on explaining
the convolutions (the new) py-execute-region undertakes.

in-a-maze-of-twisty-little-passages-ly y'rs  - tim










Replied: Tue, 25 Feb 1992 19:00:19 +0100
Replied: "Tim Peters <[e-mail]> +inbox"
Received: by charon.cwi.nl with SMTP; Mon, 24 Feb 1992 04:32:13 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05552; Sun, 23 Feb 92 22:32:13 -0500
Received: from ksr.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 223130.12213; Sun, 23 Feb 1992 22:31:30 EST
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA16642; Sun, 23 Feb 92 22:02:36 EST
Received: by kaos.ksr.com (4.0/SMI-3.2)
    id AA03606; Sun, 23 Feb 92 22:02:35 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: (Emacs python-mode.el) Patch 1.03 -> 1.04
Date: Sun, 23 Feb 92 22:02:34 EST
From: Tim Peters <[e-mail]>

If you're curious about why `C-c |' didn't work for me on multi-line
regions, turns out it worked fine after I recompiled Python without the
GNU Readline library (& thanks to Guido for suggesting that).  I don't
know any detail about *why* Readline got in the way, because it's
irrelevant to the real problem:  there are any number of obscure OS-
related things that can go wrong in trying to send a long string to a
process.

So this patch redoes the `C-c |' and `C-c C-c' commands in a way that
tries to sidestep all the known problems, both the OS-related headaches
and the Python's-syntax-is-a-little-different-in-interactive-mode
headaches.  Seems to work well for me!  Let me know if it doesn't for
you.

The major remaining glitches seem too hard to fix without special help
from Python, and have to do with sending a region to an active Python
process:

1) Because the functions send an altered form of the region to Python,
   in case of a syntax or runtime error the line numbers reported by
   Python may not be right, and you may see an extra tab in front of
   lines that Python echoes.

2) In case of a runtime error, in interactive mode Python (apparently)
   doesn't save the input lines to echo back to you.  This makes sense
   when you're typing in lines one at a time, but `C-c |' is essentially
   trying to use an interactive Python in a batch fashion:  if you hit a
   runtime error while executing a region's code, you won't be shown the
   line that triggered the error.

Maybe it would be better overall (it would certainly be less hassle for
me <grin>) to write the region into a /tmp file and then just send a
line to Python to tell it to exec the contents of that file.  The reason
the attached code doesn't settle for that is that the error msgs are
then even poorer.

Etc.  Guido & I are arguing about this stuff in the background.  In the
meantime, I hope you'll find this pleasant enough.

better-than-what-you-had-anyway-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

Change log:

Sun Feb 23 18:06:30 1992  tim
version 1.04
lots of hacks for execute-code cmds
    replaced py-execute-region
    new helper py-process-filter
    new helper py-process-send-string-wait
    new helper py-append-to-process-buffer
    removed to-do's as "done":
;; - add a newline when executing buffer ending in partial line
;; - suppress prompts when executing regions
    removed to-do because i like the current behavior better:
;; - switch back to previous buffer when starting shell
    fleshed out docs for py-execute-buffer

Patch:

*** python-mode.el    Sun Feb 23 21:18:03 1992
--- ../python-mode.el    Sun Feb 23 21:01:57 1992
***************
*** 1,4 ****
! ;;; Major mode for editing Python programs, version 1.03
  ;; by: Michael A. Guravage
  ;;     Guido van Rossum <[e-mail]>
  ;;     Tim Peters <[e-mail]>
--- 1,4 ----
! ;;; Major mode for editing Python programs, version 1.04
  ;; by: Michael A. Guravage
  ;;     Guido van Rossum <[e-mail]>
  ;;     Tim Peters <[e-mail]>
***************
*** 212,226 ****

  (defun py-execute-region (start end)
    "Send the region between START and END to a Python interpreter.
! If there is a *Python* process it is used."
    (interactive "r")
!   (condition-case nil
!       (process-send-string "Python" (buffer-substring start end))
!     (error (shell-command-on-region start end py-python-command nil))))

! (defun py-execute-buffer nil
    "Send the contents of the buffer to a Python interpreter.
! If there is a *Python* process buffer it is used."
    (interactive)
    (py-execute-region (point-min) (point-max)))

--- 212,341 ----

  (defun py-execute-region (start end)
    "Send the region between START and END to a Python interpreter.
! If there is a *Python* process it is used.  A trailing newline will be
! supplied if needed.
!
! If a trailing newline must be supplied, the region is first copied to
! buffer `-Python Input-'.
!
! If a *Python* process is used, the process buffer is popped into another
! window so you can see it, and the comment
!
! \t## working on region...
!
! is inserted at the end to let you know something is happening.
!
! Following are subtleties to note when using a *Python* process:
!
! The syntax of interactive Python differs a bit from the syntax of
! `batch' Python:  in interactive mode, a top-level code block is closed
! always and only by an empty line.  So, e.g., in interactive mode this
! triggers a syntax error:
!
! for i in 1, 2, 3:
!    print i,
!
!    print i*i
!
! The `for' loop was closed by the empty line, so the indented `print i*i'
! makes no sense.
!
! This function worms around such surprises by, in effect, deleting the
! blank lines from the region before sending it to Python.  But note that
! deleting blank lines can create a (unlikely!) problem of its own:
!
! for i in 1, 2, 3:
!    print i, \\
!
!    print i*i
!
! If someone actually uses entirely blank continuation lines, gripe and
! maybe I'll fix it.
!
! Other tricks used to reduce surprises:
!
!   - In effect, an `if 1:' is inserted at the front of the region, and a
!     tab is put in front of every non-blank line in the region.  This
!     forces Python to treat the region as a unit with respect to
!     exceptions, so that the first unhandled runtime exception (divide by
!     0, etc) will abort execution of the region.
!
!     Note that in case of error, the line numbers Python reports may be
!     wrong, because of the `if 1:' inserted at the start and because
!     Python never sees the blank lines.  Note also that lines displayed
!     as part of a traceback will have an extra tab at the start.
!
!   - The lines are sent to Python one at a time, and the function waits
!     for Python to respond before sending another.  This is done for two
!     reasons:  (1) In case of a syntax error, the code detects that Python
!     is unhappy as soon as the error occurs, and stops sending more
!     lines.  (2) Sending more than one line at a time simply doesn't work
!     on many systems, for a variety of obscure reasons."
    (interactive "r")
!   (or (< start end) (error "Region is empty"))
!   (let ( (pyproc (get-process "Python")) )
!     (save-excursion
!       ;; if newline not at end, take source from a temp buffer
!       (cond
!        ( (= (char-after (1- end)) ?\n)
!      nil)
!        ( (and (< end (point-max))
!           (= (char-after end) ?\n))
!      (setq end (1+ end)))        ; lucked out
!        ;; else we have to create a newline
!        ( t
!      (let ( (temp-buffer (get-buffer-create "-Python Input-")) )
!        (copy-to-buffer temp-buffer start end)
!        (set-buffer temp-buffer)
!        (goto-char (point-max))
!        (insert-char ?\n 1)
!        (setq start (point-min)
!          end   (point-max)))))

!       ;; send the text
!       (if (null pyproc)
!       (shell-command-on-region start end py-python-command)
!     ;; else feed it one line at a time, hack upon hack
!     (unwind-protect
!         (progn
!           (set-process-filter pyproc 'py-process-filter)
!           (py-append-to-process-buffer
!            pyproc "## working on region...\n")
!           (py-process-send-string-wait pyproc "if 1:\n")
!           (goto-char start)
!           (while (< (point) end)
!         (if (looking-at "[ \t]*$"); skip blank line
!             (forward-line 1)
!           ;; else
!           (py-process-send-string-wait
!            pyproc
!            (concat "\t" (buffer-substring
!                  (point)
!                  (progn (forward-line 1) (point)))))))
!           (set-process-filter pyproc nil)
!           (process-send-string pyproc "\n"))
!       ;; unwind-protect'ed code
!       (set-process-filter pyproc nil))))))
!
! ;; throw away "... " prompts, and gripe about anything else; this is
! ;; intended to be used only while py-execute-region is feeding gimmicked
! ;; strings to Python
! (defun py-process-filter (pyproc string)
!   ;; (save-excursion
!   ;;   (set-buffer (get-buffer-create "Trace"))
!   ;;   (insert "{" string "}"))
!   (if (equal string "... ")
!       nil
!     (py-append-to-process-buffer pyproc string)
!     (error "Unexpected response from Python -- syntax error?")))
!
! (defun py-execute-buffer ()
    "Send the contents of the buffer to a Python interpreter.
! If there is a *Python* process buffer it is used.  If a clipping
! restriction is in effect, only the accessible portion of the buffer is
! sent.  A trailing newline will be supplied if needed.
!
! See the `\\[py-execute-region]' docs for an account of some subtleties."
    (interactive)
    (py-execute-region (point-min) (point-max)))

***************
*** 1127,1134 ****
       (if (bolp) "" "...")
       (buffer-substring (point) (progn (end-of-line) (point))))))

  ;; To do:
- ;; - add a newline when executing buffer ending in partial line
- ;; - suppress prompts when executing regions
- ;; - switch back to previous buffer when starting shell
  ;; - support for ptags
--- 1242,1265 ----
       (if (bolp) "" "...")
       (buffer-substring (point) (progn (end-of-line) (point))))))

+ ;; send PROCESS the STRING as input, and wait for the process to send
+ ;; something back
+ (defun py-process-send-string-wait (process string)
+   (process-send-string process string)
+   (accept-process-output process))
+
+ ;; make PROCESS's buffer visible, append STRING to it, and force display
+ (defun py-append-to-process-buffer (process string)
+   (save-excursion
+     (let* ( (proc-buf (process-buffer process))
+         (pop-up-windows t)
+         (proc-win (display-buffer proc-buf)))
+       (set-buffer proc-buf)
+       (goto-char (point-max))
+       (insert string)
+       (move-marker (process-mark process) (point-max))
+       (set-window-point proc-win (point-max))
+       (sit-for 0))))
+
  ;; To do:
  ;; - support for ptags

>>> END OF MSG










Received: by charon.cwi.nl with SMTP; Fri, 28 Feb 1992 05:17:38 +0100
Received: from ksr.com ([192.9.200.90]) by hopscotch.ksr.com with SMTP
    id AA16048; Thu, 27 Feb 1992 23:17:21 -0500
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA11879; Thu, 27 Feb 92 23:18:30 EST
Received: by kaos.ksr.com (4.0/KSR-2.0)
    id AA16305; Thu, 27 Feb 92 23:18:29 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: (Emacs python-mode.el) Patch for version 1.04 -> 1.05
Date: Thu, 27 Feb 92 23:18:28 EST
From: Tim Peters <[e-mail]>

Small changes:

  - `C-c C-b' now accepts a prefix arg as meaning "mark the following
    structure".  E.g., if you're on an `if' statement, do `C-u C-c C-b'
    and the region will be set to the `if' block plus all the following
    `elif' and `else' blocks (if any) that belong to that `if'
    structure.  Handy when it's needed, but perhaps that's so rarely
    that you'll have a hard time remembering how to do it <0.7 grin>.

    If anyone has written Elisp that calls py-mark-block, note that you
    must change your calls because the interface has changed (the former
    only argument is now the second argument; pass `nil' as the first
    argument and it will do exactly what it did before).

  - If you ever did `M-x python-mode' by hand, you probably noticed that
    it (probably) moved point to the start of the buffer as a surprising
    side effect.  Fixed.

  - Added some words to the `C-c |' docs:  a handy hint from Guido, and
    a warning against sending regions to a Python buffer "too fast".

Plans:  None other than to rewrite the "execute region/buffer" commands
completely, contingent upon Guido releasing some experimental changes
he's made to Python itself.  If those make it into the world, sending a
region or a buffer to an active Python process will change like so:

  - Error msgs will push the envelope of the cutting edge of the state
    of the art, a veritable quantum leap beyond the stale & clumsy msgs
    of today's old-fashioned technology (oops!  forgive me; I'm working
    at a startup <grin> ...).  The unvarnished truth is that the line
    numbers will be correct, the naughty lines will actually be
    displayed, and there won't be tabs in front of them that you didn't
    put there.

  - You'll get more display options:  (1) if you want, the process buffer
    will scroll to show output as it arrives, even if it's not in the
    selected window; and, (2) if you want, you can remove the process
    buffer from all the windows and request that it "pop up" again the
    next time output arrives (handy if you have a long-running
    computation and don't won't to tie up screen area waiting for it say
    something).

  - The two above are certain (already have code that does 'em).  This
    one is iffy:  it *might* be possible to let you send over regions
    while other regions are still executing.  This is much harder to do
    than I thought it would be, even given Guido's changes (without
    which it, along with the two above, looks next to impossible).

so-in-the-absence-of-more-bug-reports-version-1.05-looks-like-"it"-
   for-a-while-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

Change log:
Thu Feb 27 22:04:27 1992  tim
version 1.05
added new arg to py-mark-block to mark whole structures (eg, if/elif/else)
    added helper py-goto-beyond-block
        changed end-of-python-def-or-class to use it
    new helper py-suck-up-first-keyword
    changed the docs
    changed other calls to py-mark-block to match new arglist
added guido's narrow-to-region hint to the py-execute-region docs
    + warning about waiting for python to finish one region
        before sending another one
changed python-mode to restore point when searching for vi tab directive
    prevents buffer movement when `M-x python-mode' done by hand

Patch:

*** python-mode.el    Thu Feb 27 22:36:57 1992
--- ../python-mode.el    Thu Feb 27 22:17:59 1992
***************
*** 1,4 ****
! ;;; Major mode for editing Python programs, version 1.04
  ;; by: Michael A. Guravage
  ;;     Guido van Rossum <[e-mail]>
  ;;     Tim Peters <[e-mail]>
--- 1,4 ----
! ;;; Major mode for editing Python programs, version 1.05
  ;; by: Michael A. Guravage
  ;;     Guido van Rossum <[e-mail]>
  ;;     Tim Peters <[e-mail]>
***************
*** 181,186 ****
--- 181,187 ----
    ;; for a rarity, we give up if it's not found prior to the first
    ;; executable statement
    (let ( (case-fold-search nil)
+      (start (point))
       new-tab-width)
      (if (re-search-forward
       "^[ \t]*#[ \t]*vi:set[ \t]+tabsize=\\([0-9]+\\):"
***************
*** 194,200 ****
            nil
          (setq tab-width new-tab-width)
          (message "Caution: tab-width changed to %d" new-tab-width)
!         (if py-beep-if-tab-change (beep))))))

    (run-hooks 'py-mode-hook))

--- 195,202 ----
            nil
          (setq tab-width new-tab-width)
          (message "Caution: tab-width changed to %d" new-tab-width)
!         (if py-beep-if-tab-change (beep)))))
!     (goto-char start))

    (run-hooks 'py-mode-hook))

***************
*** 225,232 ****
--- 227,244 ----

  is inserted at the end to let you know something is happening.

+ Hint:  If you want to execute part of a Python file several times (e.g.,
+ perhaps you're developing a function and want to flesh it out a bit at a
+ time), use `\\[narrow-to-region]' to restrict the buffer to the region of interest,
+ and send the code to a *Python* process via `\\[py-execute-buffer]' instead.
+
  Following are subtleties to note when using a *Python* process:

+ Related to the following (but in an obscure way), after you send a
+ region to a *Python* process, wait for Python to finish it before
+ sending another region.  Fixing this under the current scheme is
+ difficult, but feel free to try <grin>.
+
  The syntax of interactive Python differs a bit from the syntax of
  `batch' Python:  in interactive mode, a top-level code block is closed
  always and only by an empty line.  So, e.g., in interactive mode this
***************
*** 737,751 ****
  Returns the position of the start of the def or class."
    (interactive "P")            ; raw prefix arg
    (beginning-of-python-def-or-class class)
!   (prog1 (point)
!     (if (looking-at py-colon-line-re)
!     (py-mark-block 'just-move)
!       (py-goto-beyond-final-line))))

  ;;; Functions for marking regions

! (defun py-mark-block (&optional just-move)
!   "Mark following block of lines.
  Easier to use than explain.  It sets the region to an `interesting'
  block of succeeding lines.  If point is on a blank line, it goes down to
  the next non-blank line.  That will be the start of the region.  The end
--- 749,760 ----
  Returns the position of the start of the def or class."
    (interactive "P")            ; raw prefix arg
    (beginning-of-python-def-or-class class)
!   (prog1 (point) (py-goto-beyond-block)))

  ;;; Functions for marking regions

! (defun py-mark-block (&optional extend just-move)
!   "Mark following block of lines.  With prefix arg, mark structure.
  Easier to use than explain.  It sets the region to an `interesting'
  block of succeeding lines.  If point is on a blank line, it goes down to
  the next non-blank line.  That will be the start of the region.  The end
***************
*** 754,766 ****
   - If a comment, the region will include all succeeding comment lines up
     to (but not including) the next non-comment line (if any).

!  - If a code line that opens a new block, the region will include all
!    succeeding lines up to (but not including) the next code statement
!    (if any) that's indented no more than the starting line, except that
!    trailing blank and comment lines are excluded.  E.g., if the starting
!    line is a `def' statement, the region will be set to the full
!    function definition, but without any trailing `noise' lines.

   - Else the region will include all succeeding lines up to (but not
     including) the next blank line, or code or indenting-comment line
     indented strictly less than the starting line.  Trailing indenting
--- 763,789 ----
   - If a comment, the region will include all succeeding comment lines up
     to (but not including) the next non-comment line (if any).

!  - Else if a prefix arg is given, and the line begins one of these
!    structures:
! \tif elif else try except finally for while def class
!    the region will be set to the body of the structure, including
!    following blocks that `belong' to it, but excluding trailing blank
!    and comment lines.  E.g., if on a `try' statement, the `try' block and
!    all (if any) of the following `except' and `finally' blocks that
!    belong to the `try' structure will be in the region.  Ditto for
!    if/elif/else and for/else structures, and (a bit degenerate, since
!    they're always one-block structures) while, def and class blocks.

+  - Else if no prefix argument is given, and the line begins a Python
+    block (see list above), and the block is not a `one-liner' (i.e., the
+    statement ends with a colon, not with code), the region will include
+    all succeeding lines up to (but not including) the next code
+    statement (if any) that's indented no more than the starting line,
+    except that trailing blank and comment lines are excluded.  E.g., if
+    the starting line begins a multi-statement `def' structure, the
+    region will be set to the full function definition, but without any
+    trailing `noise' lines.
+
   - Else the region will include all succeeding lines up to (but not
     including) the next blank line, or code or indenting-comment line
     indented strictly less than the starting line.  Trailing indenting
***************
*** 770,779 ****
  A msg identifying the location of the mark is displayed in the echo
  area; or do `\\[exchange-point-and-mark]' to flip down to the end.

! If called from a program and optional argument JUST-MOVE is not nil,
! instead just moves to the end of the block, and does not set mark or
! display a msg."
!   (interactive)
    (py-goto-initial-line)
    ;; skip over blank lines
    (while (and
--- 793,803 ----
  A msg identifying the location of the mark is displayed in the echo
  area; or do `\\[exchange-point-and-mark]' to flip down to the end.

! If called from a program, optional argument EXTEND plays the role of the
! prefix arg, and if optional argument JUST-MOVE is not nil, just moves to
! the end of the block (& does not set mark or display a msg)."
!
!   (interactive "P")            ; raw prefix arg
    (py-goto-initial-line)
    ;; skip over blank lines
    (while (and
***************
*** 784,790 ****
        (error "Hit end of buffer without finding a non-blank stmt"))
    (let ( (initial-pos (point))
       (initial-indent (current-indentation))
!      last-pos)            ; position of last stmt in region
      (cond
       ;; if comment line, suck up the following comment lines
       ((looking-at "[ \t]*#")
--- 808,821 ----
        (error "Hit end of buffer without finding a non-blank stmt"))
    (let ( (initial-pos (point))
       (initial-indent (current-indentation))
!      last-pos            ; position of last stmt in region
!      (followers
!       '( (if elif else) (elif elif else) (else)
!          (try except finally) (except except finally) (finally)
!          (for else)
!          (def) (class) (while) ) )
!      first-symbol next-symbol)
!
      (cond
       ;; if comment line, suck up the following comment lines
       ((looking-at "[ \t]*#")
***************
*** 791,797 ****
        (re-search-forward "^[ \t]*[^ \t#]" nil 'move) ; look for non-comment
        (re-search-backward "^[ \t]*#")    ; and back to last comment in block
        (setq last-pos (point)))
!      ;; else if line opens a block, search for next stmt indented <=
       ((looking-at py-colon-line-re)
        (while (and
            (setq last-pos (point))    ; always true -- side effect
--- 822,844 ----
        (re-search-forward "^[ \t]*[^ \t#]" nil 'move) ; look for non-comment
        (re-search-backward "^[ \t]*#")    ; and back to last comment in block
        (setq last-pos (point)))
!
!      ;; else if line is a block line and EXTEND given, suck up
!      ;; the whole structure
!      ((and extend
!        (setq first-symbol (py-suck-up-first-keyword) )
!        (assq first-symbol followers))
!       (while (and
!           (or (py-goto-beyond-block) t) ; side effect
!           (forward-line -1)        ; side effect
!           (setq last-pos (point))    ; side effect
!           (py-goto-statement-below)
!           (= (current-indentation) initial-indent)
!           (setq next-symbol (py-suck-up-first-keyword))
!           (memq next-symbol (cdr (assq first-symbol followers))))
!     (setq first-symbol next-symbol)))
!
!      ;; else if line *opens* a block, search for next stmt indented <=
       ((looking-at py-colon-line-re)
        (while (and
            (setq last-pos (point))    ; always true -- side effect
***************
*** 798,803 ****
--- 845,851 ----
            (py-goto-statement-below)
            (> (current-indentation) initial-indent))
      nil))
+
       ;; else plain code line; stop at next blank line, or stmt or
       ;; indenting comment line indented <
       (t
***************
*** 1165,1170 ****
--- 1213,1228 ----
            (not (eobp)))
      (forward-line 1)))

+ ;; go to point right beyond final line of block begun by the current
+ ;; line.  This is the same as where py-goto-beyond-final-line goes
+ ;; unless we're on colon line, in which case we go to the end of the
+ ;; block.
+ ;; assumes point is at bolp
+ (defun py-goto-beyond-block ()
+   (if (looking-at py-colon-line-re)
+       (py-mark-block nil 'just-move)
+     (py-goto-beyond-final-line)))
+
  ;; t iff on continuation line == preceding line ends with backslash
  ;; that's not in a comment
  (defun py-continuation-line-p ()
***************
*** 1242,1247 ****
--- 1300,1313 ----
       (if (bolp) "" "...")
       (buffer-substring (point) (progn (end-of-line) (point))))))

+ ;; assuming point at bolp, return first keyword ([a-z]+) on the line,
+ ;; as a Lisp symbol; return nil if none
+ (defun py-suck-up-first-keyword ()
+   (let ( (case-fold-search nil) )
+     (if (looking-at "[ \t]*\\([a-z]+\\)\\b")
+     (intern (buffer-substring (match-beginning 1) (match-end 1)))
+       nil)))
+
  ;; send PROCESS the STRING as input, and wait for the process to send
  ;; something back
  (defun py-process-send-string-wait (process string)
***************
*** 1252,1258 ****
  (defun py-append-to-process-buffer (process string)
    (save-excursion
      (let* ( (proc-buf (process-buffer process))
!         (pop-up-windows t)
          (proc-win (display-buffer proc-buf)))
        (set-buffer proc-buf)
        (goto-char (point-max))
--- 1318,1324 ----
  (defun py-append-to-process-buffer (process string)
    (save-excursion
      (let* ( (proc-buf (process-buffer process))
!         (pop-up-windows t)    ; "let*" so display-buffer sees this
          (proc-win (display-buffer proc-buf)))
        (set-buffer proc-buf)
        (goto-char (point-max))

>>> END OF MSG










Received: by charon.cwi.nl with SMTP; Mon, 2 Mar 1992 08:55:47 +0100
Received: from ksr.com ([192.9.200.90]) by hopscotch.ksr.com with SMTP
    id AA21815; Mon, 2 Mar 1992 02:55:37 -0500
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA21967; Mon, 2 Mar 92 02:56:55 EST
Received: by kaos.ksr.com (4.0/KSR-2.0)
    id AA12872; Mon, 2 Mar 92 02:56:53 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: FYI, an exception-handling trick
Date: Mon, 02 Mar 92 02:56:52 EST
From: Tim Peters <[e-mail]>

Maybe this is obvious to y'all, and apologies in advance if so.  Wasn't
obvious to me, and it seems like a pretty slick trick, so ...

When writing a function that doesn't (or can't) trust its caller to have
passed good stuff-- when they may have passed something that will cause
an unpredictable exception, and it's not easy to check that in advance
--I've been handling it like this:

try:
    <dangerous code>
except:                    # catch every possible goof
    print 'Unhappy with what you passed!'
    print 'But it\'s not my fault, it\'s yours!'
    print 'Wish I could tell you more, but I\'m too lazy to write'
    print 'an "except" clause for every possible problem.'
    raise UnhappyError

What I really want here is some way to pass the original exception up to
the caller, but to print my own msg first so that the user doesn't
assume that the problem was caused by my code <grin>.

This seems to do the trick, & quite pleasantly:

bad_user = 1                  # assume they screwed up
try:
    <dangerous code>
    bad_user = 0            # guess they didn't -- this time
finally:
    if bad_user: print 'Bad user!'

If nothing goes wrong, bad_user is set to 0 and so the 'finally' block
just falls through.  If something does go wrong in '<dangerous code>',
Python aborts executing the 'try' block, so bad_user does not get
zeroed, so the 'finally' block prints 'Bad user!', and the exception is
passed up.

example-attached-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

This is module example.py:

import regexp

lambda_recognizer = \
      regexp.compile( '^[ \t]*lambda[ \t]*\(' ).match

def map( l, f ):
    if type(f) is type(''):

    try: paren_index = lambda_recognizer(f)[0][1] - 1
    except:
        print 'Error in map, arg 2:  string not a lambda'
        raise ValueError, `f`

    f = 'def f' + f[paren_index:]    # 'lambda' -> 'def f'
    bad = 1                # guilty until proven innocent
    try:
        exec( f + '\n' )        # creates local func 'f'
        bad = 0
    finally:
        if bad:
        print 'Error in map, arg 2:  ' + \
              'couldn\'t exec ' + `f`

    ans = []
    for elt in l: ans.append( f(elt) )
    return ans

And a short session illustrating it:

>>> from example import map
>>> a = [1, 2, 8]
>>> def p1(n): return n+1
...
>>> map( a, p1 )
[2, 3, 9]
>>> map( a, 'lambda(n): return n*n' )
[1, 4, 64]
>>> map( a, 'lamda(n): return n*n' )
Error in map, arg 2:  string not a lambda
Unhandled exception: ValueError: 'lamda(n): return n*n'
Stack backtrace (innermost last):
  File "<stdin>", line 1
  File "./example.py", line 12
    raise ValueError, `f`
>>> map( a, 'lambda(n): return n*' )
Error in map, arg 2:  couldn't exec 'def f(n): return n*'
Unhandled exception: SyntaxError: invalid syntax
Stack backtrace (innermost last):
  File "<stdin>", line 1
  File "./example.py", line 17
    exec( f + '\n' )        # creates local func 'f'
>>> END OF MSG










Received: by charon.cwi.nl with SMTP; Mon, 2 Mar 1992 20:48:02 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa13587;
          2 Mar 92 14:47 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA11623; Mon, 2 Mar 92 14:47:08 EST
Date: Mon, 2 Mar 92 14:47:08 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re:  FYI, an exception-handling trick
Cc: [e-mail]

[e-mail]>
>
> Maybe this is obvious to y'all, and apologies in advance if so.  Wasn't
> obvious to me, and it seems like a pretty slick trick, so ...
>
> When writing a function that doesn't (or can't) trust its caller to have
> passed good stuff-- when they may have passed something that will cause
> an unpredictable exception, and it's not easy to check that in advance
> --I've been handling it like this:
>
> try:
>     <dangerous code>
> except:                    # catch every possible goof
>     print 'Unhappy with what you passed!'
>     print 'But it\'s not my fault, it\'s yours!'
>     print 'Wish I could tell you more, but I\'m too lazy to write'
>     print 'an "except" clause for every possible problem.'
>     raise UnhappyError
>
> What I really want here is some way to pass the original exception up to
> the caller, but to print my own msg first so that the user doesn't
> assume that the problem was caused by my code <grin>.
>

Well, there USED to be an easy ( but not-documented, so not obvious )
way - the sys module contained the objects sys.exc_type & sys.exc_value,
so I used to be able to:

try:
   <dangerous code>
except:
   print my_msg
   raise sys.exc_type,sys.exc_value


This WAS an undocumented feature, but it seems to have disappeared ( or
moved ? ). "import sys; dir(sys)" no longer shows exc_type & exc_value.

I was at first quite distressed to discover that this feature was now
missing.  I know I'm looking for trouble relying on an undocumented
feature ... I don't mean I'm distressed because I have to change my
code. If it were moved and renamed, I wouldn't complain. [ As is is,
I'm trying to keep my complaint muted, because although I like the
functionality of the feature, I must admit it is sort of a kludge. It
might be better to have the exception be locally assignable as the
optional argument is, not a "global" symbol in module sys. ]
But now, it is quite awkward to write exception handlers that have
common code for several exceptions. (minor). AND I don't see any way
to write a generic exception handler that re-raises some of all of its
exceptions to an outer handler. (major). One has to make an exhaustive
list of exceptions, and any new ones not on the list will not be caught.

I see there are some notes about changes to error handling in error.c.
I assume that this change ( disappearance of sys.exc_type ) is related
to the changes in that code. (?)

My first impression is that I don't like this.
[ I admit I'm biased by growing up on VAX/VMS error handling, which
are a bit more "full featured" than vanilla C/UNIX signals. ]

- Steve


[ Sorry Tim, but your kludge around it looks even uglier! :-(  ]










Received: by charon.cwi.nl with SMTP; Tue, 3 Mar 1992 09:57:12 +0100
Received: from ksr.com ([192.9.200.90]) by hopscotch.ksr.com with SMTP
    id AA25884; Tue, 3 Mar 1992 03:57:13 -0500
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA25944; Tue, 3 Mar 92 03:58:35 EST
Received: by kaos.ksr.com (4.0/KSR-2.0)
    id AA23041; Tue, 3 Mar 92 03:58:34 EST
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  FYI, an exception-handling trick
Cc: [e-mail]
Date: Tue, 03 Mar 92 03:58:33 EST
From: Tim Peters <[e-mail]>

> ... there USED to be an easy ( but not-documented, so not obvious )
> way - the sys module contained the objects sys.exc_type & sys.exc_value

Just noting that several of the library modules (e.g., lib/importall.py)
still reference these guys.  I don't see them in sys either, although
they still show up in "strings" output ... hmm ... check this out!:

Python 0.9.4 alpha (>= Dec 24 1991).
Copyright 1990, 1991, 1992 Stichting Mathematisch Centrum, Amsterdam
>>> import sys
>>> dir(sys)  # not there
['argv', 'exit', 'modules', 'path', 'ps1', 'ps2', 'stderr', 'stdin', 'stdout', 'version']
>>> oldsys = dir(sys)
>>> def newsys():    # return any new things that show up in sys.*
...     ans = []
...     for elt in dir(sys):
...         if elt not in oldsys: ans.append(elt)
...     return ans
...
>>> 1/0
Unhandled exception: ZeroDivisionError: integer division
Stack backtrace (innermost last):
  File "<stdin>", line 1
>>> newsys()   # hmm!  more secret stuff for Steve <grin>
['last_traceback']
>>> def inner(): return 1/0
...
>>> def outer():
...     try: return inner()
...     except TypeError: pass
...
>>> outer()
Unhandled exception: ZeroDivisionError: integer division
Stack backtrace (innermost last):
  File "<stdin>", line 1
  File "<stdin>", line 2
  File "<stdin>", line 1
>>> newsys()    # voila!
['exc_traceback', 'exc_type', 'exc_value', 'last_traceback']
>>> sys.exc_type
'ZeroDivisionError'
>>> sys.exc_value
'integer division'
>>>

Haven't been able to get 'em to show up with anything simpler than that
(i.e., I seem to need to have at least one group of 'except' blocks
*not* catch the exception, and unwind at least one call level).

So they're there, but hard to guess when <grin>.  Yo, Guido, feature or
bug?  I didn't know about them before, so can't tell whether this is the
way they always worked.  Offhand it sure looks like it would be more
pleasant/useful if they were set every time there's an exception ...

>  ... One has to make an exhaustive list of exceptions, and any new
>  ones not on the list will not be caught.

No argument from me, Steve -- seems to me that exception-handling gets
used when I have a very specific potential problem (in which case one or
two specific 'except' blocks do the trick), or when I have no idea what
might go wrong but don't want to crash regardless (in which case an
exhaustive list is just impossible to maintain as things change).

>  ...
>  [ Sorry Tim, but your kludge around it looks even uglier! :-(  ]

as-a-long-time-fortran-programmer-i'm-immune-to-compliments<grin>-ly
   y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










To: Tim Peters <[e-mail]>
Subject: Re: Deadly problem in src/strtod.c
In-reply-to: Your message of "Tue, 03 Mar 1992 03:12:49 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 03 Mar 1992 10:16:54 +0100
Sender: guido

Yeah, my reliance on strtol/strtod has kept causing problems.  I've
finally decided to provide complete, working PD implementations of
each in the next release.  Source attached, in case you'd like to have
a look at their robustness.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Kemal Ataturk had an entire menagerie called Abdul."










Received: by charon.cwi.nl with SMTP; Tue, 3 Mar 1992 13:07:43 +0100
Received: by voorn.cwi.nl with SMTP; Tue, 3 Mar 1992 12:07:40 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: sys.exc_type etc.
In-Reply-To: Your message of "Tue, 03 Mar 1992 03:58:33 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 03 Mar 1992 13:07:37 +0100
Sender: [e-mail]

Looks like Steve and Tim have uncovered another murky area in Python...

To summarize the story so far for our new readers, and for those who
may not yet have acquired the Python fluency needed to read long
listings of Python code exemplifying a particular point:

(1) Tim wants to catch an exception, print some message, and then
re-raise the same exception, without ever caring *which* exception he
caught, as long as he re-raises the same one that he caught.  He
discovers that this is possible using try...finally and a Boolean
variable.

(2) Steven replies that there used to be undocumented variables
sys.exc_type and sys.exc_value identifying the most recent exception,
which could be used to re-raise the exception, but he can't find them
in his current Python version.  He also remarks that this is cleaner
than using try...finally.

(3) Tim discovers that sys.exc_type etc. still exist, but only get set
under obscure circumstances involving at least one try...except block
that does not catch the exception, and one stack unwind.  He then
expresses the wish that sys.exc_type etc. be set each time an
exception occurs.

Now my comments:

First, I think that Tim's original solution to his problem is
preferable over Steven's version, because Tim's preserves the
traceback: in Steven's code the traceback printed by the interpreter
ends at the "raise sys.exc_type, sys.exc_value" statement in his
except clause, which isn't very helpful for finding the cause of the
problem.  Using "finally", on the other hand, preserves the original
traceback (which is, incidentally, saved as sys.exc_traceback in some
versions of the interpreter).

Next, an explanation of how sys.exc_type etc. work is in order.  I
added them as an afterthought when I found out that if an exception
handler handles several types of exceptions at a time, it often needs
to know which exception occurred (if only to print the right message).
I played with the thought of changing the syntax so the handler could
specify a variable in which to receive the exception type (just like
it can already do for the exception's "parameter" or "associated
value"), but quickly realized that the feature is most needed for
default "except:" clauses, where adding new syntax was impossible to
do to in an elegant, yet backward-compatible way!  At that time,
changing the syntax in an incompatible way would already be rather
painful, so I opted for some secret variables.  (And forgot to
document them properly -- sorry about that!)

Now, the choice of *when* sys.exc_type is set must be explained.  (I
won't mention sys.exc_value again, since it is set whenever
sys.exc_type is set.)  Tim thinks he wants them set each time an
exception occurs, but there's a problem with that.  When searching for
an exception handler, the interpreter may execute a lot of user code:
evaluating the expressions in except clause headers, but also finally
clauses of inner try statements.  All this code may itself raise
exceptions, as long as it catches them -- so if sys.exc_type were set
each time an exception occured, an outer exception handle might see
the wrong exception type.  For example:

    try:
        try:
            1/0
        finally:
            try:
                raise EOFError
            except:
                pass
    except:
        print sys.exc_type, ':', sys.exc_value

The solution is to set sys.exc_type at the moment the exception
handler is entered.  (Note that internally in the interpreter, there
is no confusion between exceptions occurring in nested pieces of code
-- it keeps them on its internal stack.)  Because of the way the
interpreted code is generated, the interpreter actually assigns to
sys.exc_type each time it finds there are except clauses to consider,
just before evaluating the first clause's exception or list of
exceptions.  This is not done for finally clauses -- these are treated
completely different from except clauses.  I know I have changed the
policy that determines when sys.exc_type is set several times; in my
own, still experimental version (which I call 0.9.6) it is set
independent of whether the exception is being handled or not.  The
simplest case that sets it is:

    try:
        1/0
    except:
        pass

It also works with "except RuntimeError:" or "except EOFError:" instead
of "except:".  I mayu have changed this since 0.9.4 (the latest
distributed version) in order to support the new tracer/debugger
feature.

It is debatable whether sys.exc_type should be set when there is no
except clause and the user gets thrown back in the interactive main
loop.  This isn't done currently, because I haven't encountered a need
for it yet, but I could easily added if there is justified demand.  It
might be better to use different variable names in this case: I
already save the traceback info, under the name sys.last_traceback.
The distinction is useful: like sys.exc_type, sys.exc_traceback
contains rather volatile information (overwritten each time an
exception gets handled), while sys.last_traceback remains valid until
the next primary prompt, at least.

In fact, this made so much sense that I've gone to the source and
added sys.last_type and sys.last_value.  I've also documented all six
variables in the Library Reference.  So there's no need to change
existing, working code that uses any of these, unless this message
triggers a discussion that results in a cleaner design or better names
or whatever other changes might be needed -- folks, speak now or be
silent forever! :-)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"One's never alone with a rubber duck."










Received: by charon.cwi.nl with SMTP; Tue, 3 Mar 1992 21:18:08 +0100
Received: from prg.oxford.ac.uk by eros.uknet.ac.uk via JANET with NIFTP (PP)
          id <[e-mail]>; Tue, 3 Mar 1992 19:43:04 +0000
Received: from lucrece.robots (lucrece-gate.robots) by prg.oxford.ac.uk
          id AA03690; Tue, 3 Mar 92 19:42:23 GMT
Received: by uk.ac.oxford.robots (4.1/Robots 1.2m (20-Jun-90)) id AA07141;
          Tue, 3 Mar 92 19:40:31 GMT
Date: Tue, 3 Mar 92 19:40:31 GMT
From: [e-mail] (Peter Ho)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: sys.exc_type etc.

I was wondering whether the problem of the nested exceptions could be
handled the way you let the interpreter handles it.  Guido says,
    (Note that internally in the interpreter, there is no confusion
    between exceptions occurring in nested pieces of code -- it keeps them
    on its internal stack.)
As you pop this internal stack would it be possible to restore the exeception
type in sys.exc_type?

        Just a thought....,
            Pete. :-)










Received: by charon.cwi.nl with SMTP; Wed, 4 Mar 1992 06:28:20 +0100
Received: from ksr.com ([192.9.200.90]) by hopscotch.ksr.com with SMTP
    id AA29283; Wed, 4 Mar 1992 00:28:18 -0500
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA29222; Wed, 4 Mar 92 00:29:41 EST
Received: by kaos.ksr.com (4.0/KSR-2.0)
    id AA08354; Wed, 4 Mar 92 00:29:40 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: sys.exc_type etc.
Cc: [e-mail]
Date: Wed, 04 Mar 92 00:29:39 EST
From: Tim Peters <[e-mail]>

>  ...
>  I played with the thought of changing the syntax so the handler could
>  specify a variable in which to receive the exception type (just like
>  it can already do for the exception's "parameter" or "associated
>  value"), but quickly realized that the feature is most needed for
>  default "except:" clauses, where adding new syntax was impossible to
>  do to in an elegant, yet backward-compatible way!

Two things here:

The current syntax is a bit error-prone already.  E.g., if I run this:

try:
    print kidding
except NameError:
    print 'No kidding!'

it (unsurprisingly) prints 'No kidding!'.  But if I put another chunk of
code before it like so:

try:
    1/0
except ZeroDivisionError, NameError:
    print 'caught the division'

try:
    print kidding
except NameError:
    print 'No kidding!'

I get:

caught the division
Unhandled exception: NameError: kidding
Stack backtrace (innermost last):
  File "exc1.py", line 7
    print kidding

The difference between the incorrect (catches only divide-by-zero, & if
that happens binds the local name 'NameError' to the argument of the
ZeroDivisionError exception):

    except ZeroDivisionError, NameError:

above and the correct (does what most people thought the one above would
do <grin>):

    except (ZeroDivisionError, NameError):

is a bit subtle, and hard to "see" when you make the mistake.

Second, if you were to change the syntax to allow specifying 'type' and
'value' variables, I think the place to do it is not on the 'except'
clauses but on the 'try' statement itself.  I.e.,

    try optional_name_or_two-tuple:

where optional_name_or_two-tuple is bound to an appropriate (type,value)
tuple if an exception occurred, and, for the benefit of 'finally'
blocks (& maybe too for following code ...), is bound to (None,None) if
no exception occurred.  E.g.,

    try exctype, excval:
        blah blah blah
    except NameError:
        # exctype is 'NameError' here, excval is the detail
    except (TypeError, EOFError), msg:
        # exctype is whichever of the two occurred, &
        # for compatibility w/ the current scheme both msg
        # & excval hold the detail
    except:
        # exctype has the type, excval the detail
    finally:    # note that the boolean-vrbl trick isn't needed
        if exctype:
            print 'bad user!  you screwed up in a way'
            print 'i couldn\'t predict!'

Having exctype available in the 'finally' block might also be handy if
clean-up actions depend on the nature of the exception.

>  ... Tim thinks he wants them [sys.exc_type etc] set each time an
>  exception occurs, but there's a problem with that.

"Each time", yes, but I didn't say exactly *when* "each time" <grin>.
Agree that setting them at the instant the exception occurs would lead
to problems.

>  The solution is to set sys.exc_type at the moment the exception
>  handler is entered.

Not sure that's quite it, either, but am sure it's half of it.

try:
    print kidding
except NameError:
    try: 1/0
    except:
    print 'sys.exc_type should certainly be a zero-divide here'
    # but what should sys.exc_type be here?

I believe what you sketched would leave me thinking I was staring at a
divide-by-zero error at the position of the comment.  But I still want
to see a NameError at that point -- the divide by zero is history at
that point.  In nested structures, I always want to see the stuff that's
relevant to the smallest *enclosing* structure; & at the position of the
comment, that's the 'try' block that suffered the name error.  The point
to that may be clearer by replacing the block at the end; I don't want
to have to know what somefunc does:

except NameError:
    somefunc()
    # what should sys.exc_type be here?

I believe Peter Ho's comment leads to the same end here, hence there's
universal convergence <grin>.  One funny side-effect:  I believe this
*implies* that sys.exc_type and sys.exc_value would always be None (or
unbound, or something else equally vacuous) if printed from a top-level
prompt (the interpreter stack is completely unwound; there is no
exception pending in the "smallest enclosing structure" because there is
no enclosing structure).  But maybe that's just another way of saying
that both the sys.exc_... and sys.last_... flavors are useful.

>  ... folks, speak now or be silent forever! :-)

Dream on <snort>.


A related question, but on a different tack.  The following program
(correctly) dies with an IndexError on the "except elist[i], val:" line:

elist = (None, NameError)

def absurd(i):
    try:
    try:
        1/0
    except DivideByZeroError:    # meant ZeroDivisionError
        print 'caught an exception that doesn\'t exist!'
    except elist[i], val:
    print 'caught the', elist[i], 'error on', val

absurd(2)

The details of that silly code are irrelevant.  The *point* is that at
the time it dies, it's trying to handle an unhandled NameError exception
from the "except DivideByZeroError" line, while that in turn was trying
to handle the unhandled ZeroDivisionError.  It bugs me (a little, & more
in the abstract sense) that the unresolved ZeroDivisionError and
NameError exceptions go unreported.  Then again, I'd never write code
with an error in an exception-handler <grin> ...

verbally y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










Received: by charon.cwi.nl with SMTP; Thu, 5 Mar 1992 17:20:17 +0100
Received: from prg.oxford.ac.uk by eros.uknet.ac.uk via JANET with NIFTP (PP)
          id <[e-mail]>; Thu, 5 Mar 1992 14:12:48 +0000
Received: from lucrece.robots (lucrece-gate.robots) by prg.oxford.ac.uk
          id AA26750; Thu, 5 Mar 92 14:12:00 GMT
Received: from robots.ox.ac.uk (miranda.robots)
          by uk.ac.oxford.robots (4.1/Robots 1.2m (20-Jun-90)) id AA08313;
          Thu, 5 Mar 92 14:10:10 GMT
Received: by robots.ox.ac.uk (4.1/robots.remoteV2.0) id AA03434;
          Thu, 5 Mar 92 14:10:29 GMT
Date: Thu, 5 Mar 92 14:10:29 GMT
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: sys.exc_type etc.

|     try optional_name_or_two-tuple:
|
| Having exctype available in the 'finally' block might also be handy if
| clean-up actions depend on the nature of the exception.
|

I like this idea of having optional exc_{type,val} variables.

| try:
|     print kidding
| except NameError:
|     try: 1/0
|     except:
|     print 'sys.exc_type should certainly be a zero-divide here'
|     # but what should sys.exc_type be here?
|
| I believe what you sketched would leave me thinking I was staring at a
| divide-by-zero error at the position of the comment.  But I still want
| to see a NameError at that point -- the divide by zero is history at
| that point.  In nested structures, I always want to see the stuff that's
| relevant to the smallest *enclosing* structure; & at the position of the
| comment, that's the 'try' block that suffered the name error.
|
| A related question, but on a different tack.  The following program
| (correctly) dies with an IndexError on the "except elist[i], val:" line:
|
| elist = (None, NameError)
|
| def absurd(i):
|     try:
|     try:
|         1/0
|     except DivideByZeroError:    # meant ZeroDivisionError
|         print 'caught an exception that doesn\'t exist!'
|     except elist[i], val:
|     print 'caught the', elist[i], 'error on', val
|
| absurd(2)
|
| The details of that silly code are irrelevant.  The *point* is that at
| the time it dies, it's trying to handle an unhandled NameError exception
| from the "except DivideByZeroError" line, while that in turn was trying
| to handle the unhandled ZeroDivisionError.

These two examples suggest to me that it is not easy to define exactly
what the smallest enclosing structure is.  Why do you consider the current
behaviour (raising IndexError) correct, whereas in the first example you say
NameError should be the correct exception returned.
    I do see your points, but having exceptions set according to where
the code is (e.g in an exception block or a try block) may make the code
difficult to understand, and the compiler could approach the complexity of
Perl ;-)

| I believe Peter Ho's comment leads to the same end here, hence there's
| universal convergence <grin>.  One funny side-effect:  I believe this
| *implies* that sys.exc_type and sys.exc_value would always be None (or
| unbound, or something else equally vacuous)

Whoops :-)

| >  ... folks, speak now or be silent forever! :-)

That's it folks,
    Pete.










Received: by charon.cwi.nl with SMTP; Fri, 6 Mar 1992 03:29:16 +0100
Received: from ksr.com ([192.9.200.90]) by hopscotch.ksr.com with SMTP
    id AA05453; Thu, 5 Mar 1992 21:26:37 -0500
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA17548; Thu, 5 Mar 92 21:28:04 EST
Received: by kaos.ksr.com (4.0/KSR-2.0)
    id AA05565; Thu, 5 Mar 92 21:28:02 EST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: sys.exc_type etc.
Cc: [e-mail]
Date: Thu, 05 Mar 92 21:28:01 EST
From: Tim Peters <[e-mail]>

>  | [tim suggests the following as a way to introduce optional
>  |  exception type-&-value-holding names w/o busting current code]
>  |     try optional_name_or_two-tuple:
>  | ...
>  I like this idea of having optional exc_{type,val} variables.

Me too, Pete, but I don't really like this syntax.  Guido hasn't said
anything but I suspect he thinks its inelegant; I'd agree (sticking the
names on the 'try' interferes with reading the non-exceptional path).

>  | try:
>  |     print kidding
>  | except NameError:
>  |     try: 1/0
>  |     except:
>  |         print 'sys.exc_type should certainly be a zero-divide here'
>  |     # but what should sys.exc_type be here?
>  |     [tim sez NameError]
>  | ...
>  |
>  | elist = (None, NameError)
>  |
>  | def absurd(i):
>  |     try:
>  |          try:
>  |             1/0
>  |          except DivideByZeroError:    # meant ZeroDivisionError
>  |              print 'caught an exception that doesn\'t exist!'
>  |     except elist[i], val:
>  |          print 'caught the', elist[i], 'error on', val
>  |
>  | absurd(2)
>  | [dies with an index error, but a name error and a divide-by-zero
>  |  error are also unhandled at this point]

>  These two examples suggest to me that it is not easy to define exactly
>  what the smallest enclosing structure is.

I don't think the examples were related:  the first was talking about
what to do when the user handles an exception, the second about what to
do when the user fails to handle the exception.  So they're very
different at the outset.

"Smallest enclosing structure" was an unfortunate phrasing in any case;
it happened to be appropriate for the specific example, but the intended
behavior (which I believe is the same as yours) is really more dynamic
than lexical.  It's hard to be precise here unless/until there's a more-
or-less formal execution model for Python; the intended behavior would
(I think) be easy to define as a modification to that.

Informally, I would like the value of sys.exc_* at a given program point
P to be defined by the following (which, in the absence of an execution
model, is phrased in a clumsy "bottom up" way):

1.  Is P in an 'except' or 'finally' block?
    If yes, then "smallest enclosing" is well-defined (in the obvious
    (lexical) way!), and I want sys.exc_* to reflect the exception (if
    any) that aborted the associated 'try' block.

    Else go to step 2.

    Subtlety:  the "(if any)" was for the benefit of 'finally' blocks,
    which may be entered even if their associated 'try' block did not
    abort.  In that case I expect sys.exc_* to be None.

2.  [the dynamic component]
    Was I called by anyone?
    If 'yes', go back to step 1 after setting P to the call site.
    Else (at top level) sys.exc_* should be None.

If we had a detailed account of how Python manages its internal
exception stack, I suspect this might all (except for the treatment of
'finally' blocks) boil down to that 'sys.exc_*' should mirror whatever
happens to be at the top of the exception stack from moment to moment.

Another way to say it:  Suppose we had the optional

    try exc_type, exc_val:

syntax.  Ignoring the bits about crawling up the call stack, I would
like sys.exc_* to return exactly what exc_type/exc_val would return at
every point, provided that I used a uniquely-named exc_type & exc_val
for each distinct 'try' block.  It's just a way to get at part of the
same functionality without introducing any new syntax.

>  Why do you consider the current behaviour (raising IndexError)
>  correct, whereas in the first example you say NameError should be the
>  correct exception returned.

Because they're the right things to do <grin>.  Here I think you're
comparing what sys.exc_* should be *bound to* when the user is
explicitly handling an exception (1st example) to what Python itself
should *do* when the user fails to handle the exception (2nd example) --
I just don't see them as being related.

Note that I would also consider other behaviors to be "correct" in the
2nd example.  When faced with multiple unhandled exceptions, Python
currently appears to report only the most recent (in time); reporting
all or reporting some or reporting only the least recent ... etc are all
OK by me, just so long as *something* gets reported.  I suspect the
current behavior is more an accident of implementation than the result
of deliberate design, though, so thought it might be interesting to
consider other behaviors.

>      I do see your points, but having exceptions set according to where
>  the code is (e.g in an exception block or a try block) may make the code
>  difficult to understand,

Sorry, I need examples here; couldn't follow your thought.

> and the compiler could approach the complexity of Perl ;-)

God forbid!  My hope/belief is that I'm trying to find a way to get at
something Python already knows anyway (and indeed *must* know else it
couldn't itself keep the exceptions straight ...).

>  | ... I believe this *implies* that sys.exc_type and sys.exc_value
>  | would always be None (or unbound, or something else equally
>  | vacuous) [when printed from a top-level prompt]
>
>  Whoops :-)

Na, Guido said that's already the way Python acts -- we're just trying
to give him an elaborate theoretical justification for keeping it that
way <grin>.

skating-on-exceptional-ice-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










Received: by charon.cwi.nl with SMTP; Fri, 6 Mar 1992 16:19:33 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa03465;
          6 Mar 92 10:14 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA16640; Fri, 6 Mar 92 10:13:57 EST
Date: Fri, 6 Mar 92 10:13:57 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: sys.exc_type etc.

I my last post, I started to add some comments on how Python exceptions
*might* be "fixed"... ,but I edited all that part out once I started to
see how "hairy" the whole thing could get.

I've only slightly been following the discussion since ( We're getting
ready for a NIH site visit concerning our grant renewal! ) but I see
it is even worse than I expected.

I DO like the idea of "try  e_type, e_val:" as possibly the best
backwards compatible syntax. They REALLY SHOULD be local names.

You guys work it all out, and wake me when you're finished!

- Steve










Replied: Sat, 07 Mar 1992 00:29:25 +0100
Replied: [e-mail]
Replied: [e-mail]
Received: by charon.cwi.nl with SMTP; Fri, 6 Mar 1992 22:03:31 +0100
Received: from prg.oxford.ac.uk by eros.uknet.ac.uk via JANET with NIFTP (PP)
          id <[e-mail]>; Fri, 6 Mar 1992 20:38:32 +0000
Received: from lucrece.robots (lucrece-gate.robots) by prg.oxford.ac.uk
          id AA17075; Fri, 6 Mar 92 20:37:45 GMT
Received: from robots.ox.ac.uk (miranda.robots)
          by uk.ac.oxford.robots (4.1/Robots 1.2m (20-Jun-90)) id AA22086;
          Fri, 6 Mar 92 20:35:54 GMT
Received: by robots.ox.ac.uk (4.1/robots.remoteV2.0) id AA04776;
          Fri, 6 Mar 92 20:36:11 GMT
Date: Fri, 6 Mar 92 20:36:11 GMT
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: sys.exc_type etc.

The following message I sent a few days ago has just bounced back.  It's
strange, but I have been receiving mail from Tim ([e-mail]) (through this
mailing list) about it.  So for the benefit of those that haven't read it,
here it is:

Subject: Re: sys.exc_type etc.

I was wondering whether the problem of the nested exceptions could be
handled the way you let the interpreter handles it.  Guido says,
    (Note that internally in the interpreter, there is no confusion
    between exceptions occurring in nested pieces of code -- it keeps them
    on its internal stack.)
As you pop this internal stack would it be possible to restore the exeception
type in sys.exc_type?

        Just a thought....,
            Pete. :-)










Received: by charon.cwi.nl with SMTP; Sat, 7 Mar 1992 00:29:26 +0100
Received: by voorn.cwi.nl with SMTP; Fri, 6 Mar 1992 23:29:24 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: bouncing messages on the python list
In-Reply-To: Your message of "Fri, 06 Mar 1992 20:36:11 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Sat, 07 Mar 1992 00:29:23 +0100
Sender: [e-mail]

>The following message I sent a few days ago has just bounced back.

I got a similar message from an earlier post.  Apparently there's one
address on the list whose host has disappeared.  I asked our sysadmin
and he said there's a bug in sendmail that loses the destination that
causes the error.  If the problem persists, I'll take the offending
person off the list until he complains.  Reposting does not appear to
be necessary.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
[I'm still thinking about the exception handler syntax...]










Received: by charon.cwi.nl with SMTP; Wed, 11 Mar 1992 19:32:33 +0100
Received: from prg.oxford.ac.uk by eros.uknet.ac.uk via JANET with NIFTP (PP)
          id <[e-mail]>; Wed, 11 Mar 1992 17:00:56 +0000
Received: from lucrece.robots (lucrece-gate.robots) by prg.oxford.ac.uk
          id AA19099; Wed, 11 Mar 92 17:00:05 GMT
Received: by uk.ac.oxford.robots (4.1/Robots 1.2m (20-Jun-90)) id AA08997;
          Wed, 11 Mar 92 16:57:58 GMT
Date: Wed, 11 Mar 92 16:57:58 GMT
From: [e-mail] (Peter Ho)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: sys.exc_type etc

I do agree with Tim that if we had
    try exc_type, exc_val:
the variables would clutter try block.  However, I think there usefulness
might outweigh it.  I agree with the suggestion made by Steve (sorry if I
got your name wrong), that these values would have to be local, so that only
visible in that try .. except .. finally .. block.  Would it be possible?

    Whilst we're on this point, Guido why didn't you make the exception
value variable in 'except' local to only that exception (like modula-3)?  You
would remove the problem that Tim pointed out of clobbering an exception
name.  I would be happy to see an example which finds this non-locality of
the exception values useful :-).

    Going back to those examples given by Tim:
>  | try:
>  |     print kidding
>  | except NameError:
>  |     try: 1/0
>  |     except:
>  |         print 'sys.exc_type should certainly be a zero-divide here'
>  |     # but what should sys.exc_type be here?
>  |     [tim sez NameError]
>  | ...
>  |
>  | elist = (None, NameError)
>  |
>  | def absurd(i):
>  |     try:
>  |         try:
>  |             1/0
>  |         except DivideByZeroError:  # meant ZeroDivisionError
>  |             print 'caught an exception that doesn\'t exist!'
>  |     except elist[i], val:
>  |         print 'caught the', elist[i], 'error on', val
>  |
>  | absurd(2)

I am coming to the belief that in both cases the value of sys.exc_type is
correct in each case.  If you have an error in your exception handler (or
before you enter the handler in the second example) then you should be told
about it.  What puzzles me though is the second example, what should happen
to sys.exc_type and exception reporting from Python, what about having a
list returned in sys.exc_type?


        Pete. 8-)










Received: by charon.cwi.nl with SMTP; Sun, 22 Mar 1992 22:16:04 +0100
Received: from pace1.cts.mtu.edu.pace by mtu.edu (4.1/SMI-4.1)
    id AA16207; Sun, 22 Mar 92 16:15:11 EST
Date: Sun, 22 Mar 92 16:15:11 EST
From: [e-mail] (ALAN BARNES)
Message-Id: <[e-mail]>
To: [e-mail]

Hi, this is my first post to the list so bear with me....I am trying to write
a simple finger server just to see if I can do it.  I basically have it working
except for a few things.  First off, it sends the passwd field.  I plan on
fixing this.  Another thing is that it is formatted terribly right now.  It just
spits the information out with no indication as to what it is.  And my real
problem is this:  I can connect to the port I am running this on.  I type in a
user name and it gives me the information for that user.  And then it closes
the connection.  But what I want to do is only kill the connection of the
person who called.  I can't seem to figure out how to do this.  So, my little
finger program will only finger one person then quit.  Any suggestions will be
appreciated.  Thanks...I am including a copy of my program...




#this is a finger program I am writing in the python language
#it isn't working so hot.....
#

import string
from time import sleep
import sys
from socket import *
from pwd import getpwnam

PORT = 45678
SIZE = 10

def main():                 #recognize this?
    if len(sys.argv) > 1:
        PORT = int(eval(sys.argv[1]))
    else:
        PORT = 45678
    s = socket(AF_INET, SOCK_STREAM)
    s.bind('', PORT)
    s.listen(3)
    conn, (remotehost, remoteport) = s.accept()
    print 'Connection from ', remotehost, ' established.'
    data = conn.recv(SIZE)
    print len(data)
    data = data[:-2]
    field = getpwnam(data)
    for x in range(len(field)):
        conn.send(string.zfill(field[x], 1))
        conn.send('\n')
    conn.send('\n')
    conn.close()

main()










Received: by charon.cwi.nl with SMTP; Mon, 23 Mar 1992 10:09:34 +0100
Received: by schelvis.cwi.nl with SMTP; Mon, 23 Mar 1992 09:09:31 GMT
Message-Id: <[e-mail]>
To: [e-mail] (ALAN BARNES)
Cc: [e-mail]
Subject:
In-Reply-To: Message by [e-mail] (ALAN BARNES) ,
         Sun, 22 Mar 92 16:15:11 EST , <[e-mail]>
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone](home)
X-Last-Band-Seen: Wild Pumpkins at Midnight (Buurvrouw, 15-3)
X-Mini-Review: Great guitarband, even acoustic...
Date: Mon, 23 Mar 1992 10:09:30 +0100
From: Jack Jansen <[e-mail]>

That's fairly simple. The reason for having separate 'listen' and
'accept' calls in the bsd socket stuff is to do exactly that. Here's
the fixed code:

#this is a finger program I am writing in the python language
#it isn't working so hot.....
#

import string
from time import sleep
import sys
from socket import *
from pwd import getpwnam

PORT = 45678
SIZE = 10

def main():                 #recognize this?
    if len(sys.argv) > 1:
        PORT = int(eval(sys.argv[1]))
    else:
        PORT = 45678
    s = socket(AF_INET, SOCK_STREAM)
    s.bind('', PORT)
    s.listen(3)
    while 1:
        conn, (remotehost, remoteport) = s.accept()
        print 'Connection from ', remotehost, ' established.'
        data = conn.recv(SIZE)
        print len(data)
        data = data[:-2]
        field = getpwnam(data)
        for x in range(len(field)):
            conn.send(string.zfill(field[x], 1))
            conn.send('\n')
        conn.send('\n')
        conn.close()

main()

--
Jack Jansen        | If I can't dance I don't want to be part of
[e-mail] | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Received: by charon.cwi.nl with SMTP; Thu, 26 Mar 1992 21:12:30 +0100
Received: by meermin.cwi.nl with SMTP; Thu, 26 Mar 1992 20:12:22 GMT
Received: by relay.CDNnet.CA (4.1/1.14)
    id AA18486; Thu, 26 Mar 92 12:11:20 PST
Date: 26 Mar 92 12:07 -0800
From: John Buchanan <[e-mail]>
To: <[e-mail]>
Reply-To: <[e-mail]>
Message-Id: <1852*[e-mail]>
Subject: Embeding python

In the abstract for the python tutorial there is a very interesting
sentence, it reads:

    Python is also suitable as an extension language for highly
    customizable C applicatons such as editors or window managers.

Unfortunately there is no discussion of this (Not that I could find) in
the documentation that came with

    Python 0.9.4 alpha (Jan 30 1992).


Does this sentence mean that it is possible to embed python into a C
program?  If this is the case could some one send me some pointers as to
how to accomplish this.

    thanks

    juancho










Received: by charon.cwi.nl with SMTP; Thu, 26 Mar 1992 21:32:15 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa18990;
          26 Mar 92 15:31 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA09390; Thu, 26 Mar 92 15:30:39 EST
Date: Thu, 26 Mar 92 15:30:39 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re:  Embeding python
Cc: [e-mail]

[e-mail] writes:
>
> In the abstract for the python tutorial there is a very interesting
> sentence, it reads:
>
>     Python is also suitable as an extension language for highly
>     customizable C applicatons such as editors or window managers.
>
> Unfortunately there is no discussion of this (Not that I could find) in
> the documentation that came with
>
>     Python 0.9.4 alpha (Jan 30 1992).
>
> Does this sentence mean that it is possible to embed python into a C
> program?  If this is the case could some one send me some pointers as to
> how to accomplish this.
>

YES.

HOW:
 First: read "misc/EXTENDING" .
 Next: Start reading the sources.

 ( Is there a step in between I'm missing, Guido ? )

Perhaps Steve Miale ( here at UVA EE|CS ) can give us a progress report
on what they are doing ? (hint,hint!)

- Steve Majewski  [e-mail]












Replied: Fri, 27 Mar 1992 14:26:40 +0100
Replied: "[e-mail] "
Received: by charon.cwi.nl with SMTP; Thu, 26 Mar 1992 21:50:07 +0100
Received: by relay.CDNnet.CA (4.1/1.14)
    id AA19151; Thu, 26 Mar 92 12:49:56 PST
Date: 26 Mar 92 12:47 -0800
From: John Buchanan <[e-mail]>
To: "Steven D. Majewski" <[e-mail]>
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <1853*[e-mail]>
Subject: Re:  Embeding python



I read misc/EXTENDING (quickly) and it seems as though it is possible but
not that straight forward.  What I was looking for was something that looks
as follows.

int load_python_program(char *pathname_to_python_program)
    /* Or some function to initialize and load python */

int run_python_program_with_arguments(arg1 arg2 arg3.....argn)
    /* call some procedure in the loaded program */

This may be far to simple, but I hope that something like this is possible.

We wish to use python in this manner since we have an application which
we have already implemented and we wish to add a programmable extension
to it.

        juancho













Received: by charon.cwi.nl with SMTP; Fri, 27 Mar 1992 10:27:01 +0100
Received: by schelvis.cwi.nl with SMTP; Fri, 27 Mar 1992 09:27:00 GMT
Message-Id: <[e-mail]>
To: John Buchanan <[e-mail]>
Cc: "Steven D. Majewski" <[e-mail]>, [e-mail]
Subject: Re: Embeding python
In-Reply-To: Message by John Buchanan <[e-mail]> ,
         26 Mar 92 12:47 -0800 , <1853*[e-mail]>
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone](home)
X-Last-Band-Seen: Wild Pumpkins at Midnight (Buurvrouw, 15-3)
X-Mini-Review: Great guitarband, even acoustic...
Date: Fri, 27 Mar 1992 10:26:59 +0100
From: Jack Jansen <[e-mail]>

Hmm... Guido'll have something to say about it when he comes in, no
doubt, but personally I think that the referenced sentence is probably
a bit too optimistic.

What you can do is turn your C program into a module, embed it in a
tiny python program and call python modules from your C code.

The python code is real simple. Assuming you call your C module 'foo',
you do something like

  import foo

  def .....    # Define all python functions here, or in other modules,
          # whatever you want...

  foo.callmymain()

Turning your program into a module isn't too much work: rename main()
to my_main() and write a wrapper module (as described in
misc/EXTENDING) that calls your main program. You can then use
dictlookup() (I think) to find python objects and call_object() to
call those objects from your C code.

Unless you have the latest python with the dynamic loading facility
you then have to create a new python binary that includes your new
module (and your old application program as well, of course). With
dynamic loading things are a bit simpler, since you can just leave a
partially linked 'foomodule.o' around somewhere in the $PYTHONPATH,
and an 'import foo' will result in the module being dynamically linked
into the running python interpreter.

Maybe Guido can provide us with a complete sceleton example?
--
Jack Jansen        | If I can't dance I don't want to be part of
[e-mail] | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Received: by charon.cwi.nl with SMTP; Fri, 27 Mar 1992 14:26:43 +0100
Received: by voorn.cwi.nl with SMTP; Fri, 27 Mar 1992 13:26:42 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Embedding python
In-Reply-To: Your message of "26 Mar 1992 12:47:00 MET."
             <1853*[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 27 Mar 1992 14:26:41 +0100
Sender: [e-mail]

Embedding Python in C is possible, but misc/EXTENDING isn't the whole
answer.  It only describes how to extend Python with code written in
C, but you still have to have a "main program" written in Python.

By definition, "embedding" means doing it the other way around, like
John writes:

>What I was looking for was something that looks as follows.
>
>int load_python_program(char *pathname_to_python_program)
>    /* Or some function to initialize and load python */
>
>int run_python_program_with_arguments(arg1 arg2 arg3.....argn)
>    /* call some procedure in the loaded program */

Such a simple interface currently does not exist, but it shouldn't be
too hard to create it, or something similar.

I hope you're a bit adventurous; then you can read pythonmain.c and
figure out how to do it.  Basically, you'll need to move all functions
from that file elsewhere, and add calls to initpython() (at least) and
setpythonpath() (probably) and setpythonargv() (perhaps) to your own
main program.  You can then call routines like run_command(string) or
run(FILEpointer, filename) to execute Python code as you wish.  There
are other run_*() functions that provide more flexibility, like
choosing which environment to use.

You'll probably find that the Python code run in this way needs access
to funactionality defined in your application, and for *that* you'll
need to do everything described in misc/EXTENDING.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"What's so unpleasant about being drunk?"
"Go ask a glass of water!"










Replied: Mon, 30 Mar 1992 11:05:12 +0200
Replied: "John Buchanan <[e-mail]> "
Received: by charon.cwi.nl with SMTP; Fri, 27 Mar 1992 19:38:08 +0100
Received: by relay.CDNnet.CA (4.1/1.14)
    id AA00598; Fri, 27 Mar 92 10:37:53 PST
Date: 27 Mar 92  9:58 -0800
From: John Buchanan <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <1855*[e-mail]>
Subject: Re: Embedding python


>Embedding Python in C is possible, but misc/EXTENDING isn't the whole
>answer.  It only describes how to extend Python with code written in
>C, but you still have to have a "main program" written in Python.
>
>By definition, "embedding" means doing it the other way around, like
>John writes:
>
>>What I was looking for was something that looks as follows.
>>
>>int load_python_program(char *pathname_to_python_program)
>>       /* Or some function to initialize and load python */
>>
>>int run_python_program_with_arguments(arg1 arg2 arg3.....argn)
>>       /* call some procedure in the loaded program */
>
>
>
>Such a simple interface currently does not exist, but it shouldn't be
>too hard to create it, or something similar.
>
>I hope you're a bit adventurous; then you can read pythonmain.c and
>figure out how to do it.  Basically, you'll need to move all functions
>from that file elsewhere, and add calls to initpython() (at least) and
>setpythonpath() (probably) and setpythonargv() (perhaps) to your own
>main program.  You can then call routines like run_command(string) or
>run(FILEpointer, filename) to execute Python code as you wish.  There
>are other run_*() functions that provide more flexibility, like
>choosing which environment to use.



I took a quick look at pythonmain.c and I have a couple of questions and or
suggestions.

main() seems simple enough, so I would like to suggest the following.

rewrite and rename main() as follows

initialize_python(int argc,char argv[])


write a separate module for python of which looks like this

the_real_python_main.c

main(int argc, char *argv[])
    {
    initialize_python(argc,argv);
    }

Now compile everything but the_real_python_main.c as a library.
compile and link python.

Now to call from a c program we do the following

initialize_python(5 ,argv);



Now I realize that this is a simple approach and is probably not going
to work as stated but I think that the idea of making the bulk of python
into a library and then having a simple front end for it is the way to go.
This allows python to be embedded quite easily and would not result in
incompatible versions of python running around.

    juancho










Received: by charon.cwi.nl with SMTP; Fri, 27 Mar 1992 20:14:41 +0100
Received: from pace1.cts.mtu.edu.pace by mtu.edu (4.1/SMI-4.1)
    id AA07693; Fri, 27 Mar 92 14:13:28 EST
From: [e-mail] (ALAN BARNES)
Message-Id: <[e-mail]>
Subject: system and open
To: [e-mail]
Date: Fri, 27 Mar 92 14:13:39 EST
X-Mailer: ELM [version 2.3 PL11]

Ok, a couple of questions.  Where is write and related functions located?
They aren't in built-in with open.  I cannot find close either.  I want to
write the output of something to a file but cannot figure out where these
commands are located.  They are only mentioned breifly in the docs I have which
I am assuming are the current ones.  Also, is there any way to get the output
of a system command assigned to a variable?  e.g. list = system('ls').  I want
to do something like this also but don't know if I would be able to.  Any ideas
are appreciated.  Thanks...

--

            +------------------------------------------------+
            |              /--------------------------\      |
            |             |  Bart Got an Erection      |     |
            | |\/\/\/|   /   Bart Didn't Use Protection \    |
            | |      |   |   Bart Got an Infection !    |    |
            | | (o)(o)   \_   _________________________/     |
            | c      _)    | /                               |
            |  | '___|    <_/     Don't be tough             |
            |  |   /              Don't be silly             |
            |  /____\             Wear a condom              |
            | /      \            on your Willy !            |
            +------------------------------------------------+
            |  M       [e-mail]                      |
            |   T      [e-mail]          |
            |    U     [e-mail]            |
            |            A.K.A.   The Artful Dodger          |
            *_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-*











Received: by charon.cwi.nl with SMTP; Fri, 27 Mar 1992 21:15:18 +0100
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa14162;
          27 Mar 92 15:10 EST
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA11258; Fri, 27 Mar 92 15:09:54 EST
Date: Fri, 27 Mar 92 15:09:54 EST
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re:  system and open
Cc: [e-mail]


>From [e-mail]>
>
> Ok, a couple of questions.  Where is write and related functions located?
> They aren't in built-in with open.  I cannot find close either.

write & close are methods of file objects, so they are built-in, even
though you don't see them in the scope of 'builtin' .


>>>import builtin
>>>dir(builtin)
['AttributeError', 'EOFError',
'IOError', 'ImportError', 'IndexError', 'KeyError',
'KeyboardInterrupt', 'MemoryError', 'NameError', 'None',
'OverflowError', 'RuntimeError', 'SyntaxError', 'SystemError',
'TypeError', 'ValueError', 'ZeroDivisionError', 'abs', 'apply', 'chr',
'dir', 'divmod', 'eval', 'exec', 'float', 'hex', 'input', 'int',
'len', 'long', 'max', 'min', 'oct', 'open', 'ord', 'pow', 'range',
'raw_input', 'reload', 'type']

>>>f = open( '/dev/tty', 'r' )
>>>f
<open file '/dev/tty', mode 'r'>

>>>f.__methods__
['close', 'flush', 'isatty', 'read', 'readline', 'readlines',
'seek', 'tell', 'write']

>>>f.write
<built-in method 'write' of some file object>
>>>f.close
<built-in method 'close' of some file object>



> Also, is there any way to get the output
> of a system command assigned to a variable?
> e.g. list = system('ls').


>>>import posix
>>>ls = posix.popen( 'ls -l', 'r' ).readlines()
>>>ls
['total 75\012',
'-rw-r--r-- 1 sdm7g 2401 Mar 27 14:55 #Re11196#\012',
'-rw------- 1 zhu 34 Mar 19 19:15 MTda01454\012',
'-rw-r--r-- 1 zhu 34 Mar 27 11:45 MTda10945\012',
'-rw------- 1 zhu 5530 Mar 19 19:15 MTvia01454\012',
'-rw------- 1 sdm7g 2270 Mar 27 14:44 Re11196\012',
'-rw------- 1 zhu 0 Mar 19 19:15 Text1454.0\012',
 .
 .
 .
'-rw------- 1 zhu 0 Mar 27 11:41 tty.txt.a10942\012']

>
> .sig deleted
>

My condolences.
That's about the WORST case of .sig virus I've seen around! :-)

- Steve Majewski     [e-mail]










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA11749 (5.65b/2.9/CWI-Amsterdam); Mon, 6 Apr 1992 16:21:06 +0200
Received: by voorn.cwi.nl with SMTP; Mon, 6 Apr 1992 14:21:05 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Python release 0.9.6 is here!
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 06 Apr 1992 16:21:04 +0200
Sender: [e-mail]

Hi folks,

I've finally finished the work on Python release 0.9.6.

Below are the README and the NEWS files from the distribution.

Ftp accessibility is through ftp.cwi.nl:/pub (Europe) and
wuarchive.wustl.edu:/pub (America).

You are encouraged to port this to your system and report any problems
you have.  If bug reports warrant it, I'll bring out a maintenance
release 0.9.7 within a few weeks.  But don't hold your breath, it may
never happen: this release is pretty rock solid as far as real bugs
are concerned, although there could be little portability problems
(the range of machines I have access to has shrunk considerably -- no
more "pure 4.3 BSD" machines around here :-( ).

==> CWI readers please note: I've installed this version in
    /usr/local, but it may take a night to reach all file servers.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Strange women, laying in ponds, distributing swords, is no basis for a
system of government."

****************************** NEWS ************************************

==============================
==> NEWS FOR RELEASE 0.9.6 <==
==============================

Misc news in 0.9.6:
- Restructured the misc subdirectory
- Reference manual completed, library manual much extended (with indexes!)
- the GNU Readline library is now distributed standard with Python
- the script "../demo/scripts/classfix.py" fixes Python modules using old
  class syntax
- Emacs python-mode.el (was python.el) vastly improved (thanks, Tim!)
- Because of the GNU copyleft business I am not using the GNU regular
  expression implementation but a free re-implementation by Tatu Ylonen
  that recently appeared in comp.sources.misc (Bravo, Tatu!)

New features in 0.9.6:
- stricter try stmt syntax: cannot mix except and finally clauses on 1 try
- New module 'os' supplants modules 'mac' and 'posix' for most cases;
  module 'path' is replaced by 'os.path'
- os.path.split() return value differs from that of old path.split()
- sys.exc_type, sys.exc_value, sys.exc_traceback are set to the exception
  currently being handled
- sys.last_type, sys.last_value, sys.last_traceback remember last unhandled
  exception
- New function string.expandtabs() expands tabs in a string
- Added times() interface to posix (user & sys time of process & children)
- Added uname() interface to posix (returns OS type, hostname, etc.)
- New built-in function execfile() is like exec() but from a file
- Functions exec() and eval() are less picky about whitespace/newlines
- New built-in functions getattr() and setattr() access arbitrary attributes
- More generic argument handling in built-in functions (see "./EXTENDING")
- Dynamic loading of modules written in C or C++ (see "./DYNLOAD")
- Division and modulo for long and plain integers with negative operands
  have changed; a/b is now floor(float(a)/float(b)) and a%b is defined
  as a-(a/b)*b.  So now the outcome of divmod(a,b) is the same as
  (a/b, a%b) for integers.  For floats, % is also changed, but of course
  / is unchanged, and divmod(x,y) does not yield (x/y, x%y)...
- A function with explicit variable-length argument list can be declared
  like this: def f(*args): ...; or even like this: def f(a, b, *rest): ...
- Code tracing and profiling features have been added, and two source
  code debuggers are provided in the library (pdb.py, tty-oriented,
  and wdb, window-oriented); you can now step through Python programs!
  See sys.settrace() and sys.setprofile(), and "../lib/pdb.doc"
- '==' is now the only equality operator; "../demo/scripts/eqfix.py" is
  a script that fixes old Python modules
- Plain integer right shift now uses sign extension
- Long integer shift/mask operations now simulate 2's complement
  to give more useful results for negative operands
- Changed/added range checks for long/plain integer shifts
- Options found after "-c command" are now passed to the command in sys.argv
  (note subtle incompatiblity with "python -c command -- -options"!)
- Module stdwin is better protected against touching objects after they've
  been closed; menus can now also be closed explicitly
- Stdwin now uses its own exception (stdwin.error)

New features in 0.9.5 (released as Macintosh application only, 2 Jan 1992):
- dictionary objects can now be compared properly; e.g., {}=={} is true
- new exception SystemExit causes termination if not caught;
  it is raised by sys.exit() so that 'finally' clauses can clean up,
  and it may even be caught.  It does work interactively!
- new module "regex" implements GNU Emacs style regular expressions;
  module "regexp" is rewritten in Python for backward compatibility
- formal parameter lists may contain trailing commas

Bugs fixed in 0.9.6:
- assigning to or deleting a list item with a negative index dumped core
- divmod(-10L,5L) returned (-3L, 5L) instead of (-2L, 0L)

Bugs fixed in 0.9.5:
- masking operations involving negative long integers gave wrong results

****************************** README **********************************

Python source distribution, release 0.9.6
-----------------------------------------

==> If you don't know yet what Python is: it's an interpreted,
    interactive, object-oriented programming language.  Read the file
    misc/BLURB for more information.

==> If you want to start compiling right away (UNIX only): cd to the
    src subdirectory, *read* and *edit* the Makefile there, and run
    make.  But it's better to read misc/BUILD first.

==> If you want to know what's new since release 0.9.4 (somehow,
    version 0.9.5 was never released): read misc/NEWS.  Older history
    is in misc/HOSTORY.

==> See the copyright notice at the end of this file.

Distribution structure
----------------------

Each subdirectory has a README file explaining its contents in more
detail.  The subdirectories at the top level are:

src/        C sources -- you build the Python binary here
lib/        Python sources for standard Python modules
demo/        Python sources for various demos of Python's abilities
doc/        LaTeX sources for the main documentation
misc/        UNIX man page, internal documentation, Emacs mode, etc.
readline/    Source for the GNU Readline library

Author
------

Guido van Rossum
CWI, dept. CST
Kruislaan 413
1098 SJ  Amsterdam
The Netherlands

E-mail: [e-mail]

Ftp access
----------

The latest Python source distribution can be ftp'ed from site
ftp.cwi.nl (IP address 192.16.184.180), directory /pub, file
python<version>.tar.Z.  You can also find PostScript of the main
Python documentation there, a Macintosh binary, and the latest stdwin
source distribution.  I try to upload copies of these files to
wuarchive.wustl.edu:/pub, to save on trans-atlantic traffic.  See also
misc/FTP.

Mailing list
------------

There is a mailing list devoted to Python programming, bugs and
design.  To subscribe, send mail containing your real name and e-mail
address in Internet form to "[e-mail]".

Copyright Notice
----------------

The Python source is copyrighted, but you can freely use and copy it
as long as you don't change or remove the copyright:

Copyright 1991, 1992 by Stichting Mathematisch Centrum, Amsterdam, The
Netherlands.

                        All Rights Reserved

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation, and that the names of Stichting Mathematisch
Centrum or CWI not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior permission.

STICHTING MATHEMATISCH CENTRUM DISCLAIMS ALL WARRANTIES WITH REGARD TO
THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS, IN NO EVENT SHALL STICHTING MATHEMATISCH CENTRUM BE LIABLE
FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

************************************************************************










Received: from hopscotch.ksr.com by charon.cwi.nl with SMTP
    id AA26513 (5.65b/2.9/CWI-Amsterdam); Tue, 7 Apr 1992 05:43:19 +0200
Received: from ksr.com ([192.9.200.90]) by hopscotch.ksr.com with SMTP
    id AA03572; Mon, 6 Apr 1992 23:43:05 -0400
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA06189; Mon, 6 Apr 92 23:45:53 EDT
Received: by kaos.ksr.com (4.0/KSR-2.0)
    id AA28100; Mon, 6 Apr 92 23:45:51 EDT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: (Emacs) python-mode.el patch, vers 1.06x -> 1.06
Date: Mon, 06 Apr 92 23:45:50 -0400
From: Tim Peters <[e-mail]>

Congratulations to Guido on another fine release!

If you're using the Emacs Python mode, the patch below will change the
experimental version (1.06x) distributed with the Python 0.9.6 release
to the "official" version (1.06).  Note that 1.06x and 1.06 both
*require* Python 0.9.6 for proper functioning (they rely on the nifty
new "execfile" builtin).

There are few visible changes from 1.05; in general, some things are
just slicker, and there are a few new user-settable variables to control
scrolling behavior and to name a temp directory.

One bugfix:  1.05 & 1.06x didn't realize that "while" loops can have an
"else" clause.  1.06 does.

One outstanding bug:  Sometimes when you're at the end of a file that
doesn't end with a newline, the indentation commands just don't work
right.  E.g., DEL may move back a single column when it should close a
block, or TAB may move to the wrong column.  Nobody has been able to
reproduce this reliably -- it seems to be a function of both the file
content and the history of inserts and deletes.  On three occasions when
this happened, I have definitely seen Emacs returning a wrong value for
the Elisp function `current-indentation', and this does appear to be the
underlying cause.  Since it a appears to be a flaky bug in some versions
of Emacs out there, there's not much I can do about it.  If it happens
to you, make sure your file ends with a newline and try again -- that's
fixed it every time for me.  And if you stumble into a reproducible case,
please send it on & I'll try to follow up on it.

have-fun!-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

Change log:

Mon Apr  6 23:14:18 1992  tim
version 1.06
beefed up py-shell docs
    point to emacs shell-mode docs
    warn against changing python's ps[12]
fixed set-up of syntax table to stop changing the syntax of the buffer
    py-mode is loaded from (probably only affects py-mode developers
    doing eval-current-buffer)
changed set-up of py-mode-map just to look more like the others
junked py-process-send-string-wait
rewrote py-execute-region, py-process-filter, py-append-to-process-buffer
    to add new scrolling features, and to use python's new execfile
    command
    new vrbl py-temp-directory
    new vrbl py-scroll-process-buffer
    new secret vrbl py-file-queue
    new helper py-make-temp-name
    new helper py-execute-file
    new helper py-delete-file-silently
new hair to try to make sure the temp files are deleted when emacs
    exits (in case buffer dies/gets_killed while files pending)
    new secret vrbl py-inherited-kill-emacs-hook
    new helper py-kill-emacs-hook
changed py-append-to-process-buffer to muck with shell-mode's "last
    input" markers so that C-c C-r and C-c C-o work intuitively
    after sending a region
added bizarre hack to py-process-filter -- major mysteries here, but
    emacs segfaults (etc) without this
added warning about trying to undo edits that occurred while process
    output is arriving -- this one's certainly Emacs's fault
    heck, maybe it's a feature!
changed py-shell to make the process buffer use python's syntax table
taught py-mark-block that 'while' loops can have an 'else' clause

Patch (1.06x -> 1.06):

*** python-mode.el    Mon Apr  6 23:10:28 1992
--- ../python-mode.el    Mon Apr  6 23:08:51 1992
***************
*** 1,4 ****
! ;;; Major mode for editing Python programs, version 1.06x
  ;; by: Michael A. Guravage
  ;;     Guido van Rossum <[e-mail]>
  ;;     Tim Peters <[e-mail]>
--- 1,4 ----
! ;;; Major mode for editing Python programs, version 1.06
  ;; by: Michael A. Guravage
  ;;     Guido van Rossum <[e-mail]>
  ;;     Tim Peters <[e-mail]>
***************
*** 100,113 ****
      (funcall ok "/usr/tmp")
      (funcall ok "/tmp")
      (funcall ok  ".")
!     (error "Couldn't find a usable temp directory")))
    "*Directory used for temp files created by a *Python* process.
  By default, the first directory from this list that exists and that you
  can write into:  the value (if any) of the environment variable TMPDIR,
  /usr/tmp, /tmp, or the current directory.")

! (defvar py-active-file nil)
! (defvar py-pending-files nil)

  ;; arrange to kill temp files no matter what
  ;; have to trust that other people are as respectful of our hook
--- 100,116 ----
      (funcall ok "/usr/tmp")
      (funcall ok "/tmp")
      (funcall ok  ".")
!     (error
!      "Couldn't find a usable temp directory -- set py-temp-directory")))
    "*Directory used for temp files created by a *Python* process.
  By default, the first directory from this list that exists and that you
  can write into:  the value (if any) of the environment variable TMPDIR,
  /usr/tmp, /tmp, or the current directory.")

! ;; have to bind py-file-queue before installing the kill-emacs hook
! (defvar py-file-queue nil
!   "Queue of Python temp files awaiting execution.
! Currently-active file is at the head of the list.")

  ;; arrange to kill temp files no matter what
  ;; have to trust that other people are as respectful of our hook
***************
*** 293,307 ****
  your output from Python's output, and assumes that `>>> ' at the start
  of a line is a prompt from Python.  Similarly, the Emacs Shell mode code
  assumes that both `>>> ' and `... ' at the start of a line are Python
! prompts.  Bad things can happen if you fool either mode."
    (interactive)
    (require 'shell)
    (switch-to-buffer-other-window (make-shell "Python" py-python-command))
    (make-local-variable 'shell-prompt-pattern)
    (setq shell-prompt-pattern "^>>> \\|^\\.\\.\\. ")
!   (set-process-filter
!    (get-buffer-process (current-buffer))
!    'py-process-filter))

  (defun py-execute-region (start end)
    "Send the region between START and END to a Python interpreter.
--- 296,318 ----
  your output from Python's output, and assumes that `>>> ' at the start
  of a line is a prompt from Python.  Similarly, the Emacs Shell mode code
  assumes that both `>>> ' and `... ' at the start of a line are Python
! prompts.  Bad things can happen if you fool either mode.
!
! Warning:  If you do any editing *in* the process buffer *while* the
! buffer is accepting output from Python, do NOT attempt to `undo' the
! changes.  Some of the output (nowhere near the parts you changed!) may
! be lost if you do.  This appears to be an Emacs bug, an unfortunate
! interaction between undo and process filters; the same problem exists in
! non-Python process buffers using the default (Emacs-supplied) process
! filter."
    (interactive)
    (require 'shell)
    (switch-to-buffer-other-window (make-shell "Python" py-python-command))
    (make-local-variable 'shell-prompt-pattern)
    (setq shell-prompt-pattern "^>>> \\|^\\.\\.\\. ")
!   (set-process-filter (get-buffer-process (current-buffer))
!               'py-process-filter)
!   (set-syntax-table py-mode-syntax-table))

  (defun py-execute-region (start end)
    "Send the region between START and END to a Python interpreter.
***************
*** 331,358 ****
  limit is (indirectly) inherited from libc's mktemp(3).  Python mode does
  not try to protect you from exceeding the limit.  It's extremely
  unlikely that you'll get anywhere close to the limit in practice, unless
! you're trying to be a jerk <grin>."
    (interactive "r")
    (or (< start end) (error "Region is empty"))
    (let ( (pyproc (get-process "Python"))
!      fname)
!       (if (null pyproc)
!       (shell-command-on-region start end py-python-command)
!     ;; else feed it thru a temp file
!     (setq fname (py-make-temp-name))
!     (write-region start end fname nil 'no-msg)
!     (if py-active-file
!         (progn
!           (setq py-pending-files
!             (append py-pending-files (list fname)))
!           (message "File %s queued for execution" fname))
!       ;; else
!       (py-execute-file pyproc fname)))))

  (defun py-execute-file (pyproc fname)
-   (if py-active-file
-       (error "Internal error in py-execute-file"))
-   (setq py-active-file fname)
    (py-append-to-process-buffer
     pyproc
     (format "## working on region in file %s ...\n" fname))
--- 342,366 ----
  limit is (indirectly) inherited from libc's mktemp(3).  Python mode does
  not try to protect you from exceeding the limit.  It's extremely
  unlikely that you'll get anywhere close to the limit in practice, unless
! you're trying to be a jerk <grin>.
!
! See the `\\[py-shell]' docs for additional warnings."
    (interactive "r")
    (or (< start end) (error "Region is empty"))
    (let ( (pyproc (get-process "Python"))
!       fname)
!     (if (null pyproc)
!     (shell-command-on-region start end py-python-command)
!       ;; else feed it thru a temp file
!       (setq fname (py-make-temp-name))
!       (write-region start end fname nil 'no-msg)
!       (setq py-file-queue (append py-file-queue (list fname)))
!       (if (cdr py-file-queue)
!       (message "File %s queued for execution" fname)
!     ;; else
!     (py-execute-file pyproc fname)))))

  (defun py-execute-file (pyproc fname)
    (py-append-to-process-buffer
     pyproc
     (format "## working on region in file %s ...\n" fname))
***************
*** 390,396 ****
        (insert string)
        (move-marker pmark (point))
        (setq file-finished
!         (and py-active-file
           (equal ">>> "
              (buffer-substring
               (prog2 (beginning-of-line) (point)
--- 398,404 ----
        (insert string)
        (move-marker pmark (point))
        (setq file-finished
!         (and py-file-queue
           (equal ">>> "
              (buffer-substring
               (prog2 (beginning-of-line) (point)
***************
*** 405,416 ****
      (set-buffer curbuf)
      (if file-finished
      (progn
!       (py-delete-files-silently py-active-file)
!       (setq py-active-file nil)
!       (if py-pending-files
!           (progn
!         (py-execute-file pyproc (car py-pending-files))
!         (setq py-pending-files (cdr py-pending-files))))))))

  (defun py-execute-buffer ()
    "Send the contents of the buffer to a Python interpreter.
--- 413,422 ----
      (set-buffer curbuf)
      (if file-finished
      (progn
!       (py-delete-file-silently (car py-file-queue))
!       (setq py-file-queue (cdr py-file-queue))
!       (if py-file-queue
!         (py-execute-file pyproc (car py-file-queue)))))))

  (defun py-execute-buffer ()
    "Send the contents of the buffer to a Python interpreter.
***************
*** 839,849 ****
  \tif elif else try except finally for while def class
     the region will be set to the body of the structure, including
     following blocks that `belong' to it, but excluding trailing blank
!    and comment lines.  E.g., if on a `try' statement, the `try' block and
!    all (if any) of the following `except' and `finally' blocks that
     belong to the `try' structure will be in the region.  Ditto for
!    if/elif/else and for/else structures, and (a bit degenerate, since
!    they're always one-block structures) while, def and class blocks.

   - Else if no prefix argument is given, and the line begins a Python
     block (see list above), and the block is not a `one-liner' (i.e., the
--- 845,856 ----
  \tif elif else try except finally for while def class
     the region will be set to the body of the structure, including
     following blocks that `belong' to it, but excluding trailing blank
!    and comment lines.  E.g., if on a `try' statement, the `try' block
!    and all (if any) of the following `except' and `finally' blocks that
     belong to the `try' structure will be in the region.  Ditto for
!    if/elif/else, for/else and while/else structures, and (a bit
!    degenerate, since they're always one-block structures) def and class
!    blocks.

   - Else if no prefix argument is given, and the line begins a Python
     block (see list above), and the block is not a `one-liner' (i.e., the
***************
*** 883,890 ****
       (followers
        '( (if elif else) (elif elif else) (else)
           (try except finally) (except except finally) (finally)
!          (for else)
!          (def) (class) (while) ) )
       first-symbol next-symbol)

      (cond
--- 890,897 ----
       (followers
        '( (if elif else) (elif elif else) (else)
           (try except finally) (except except finally) (finally)
!          (for else) (while else)
!          (def) (class) ) )
       first-symbol next-symbol)

      (cond
***************
*** 1057,1070 ****
  %c:py-execute-region
  %c:py-shell

- Warning:  If you do any editing *in* the process buffer *while* the
- buffer is accepting output from Python, do NOT attempt to `undo' the
- changes.  Some of the output (nowhere near the parts you changed!) may
- be lost if you do.  This appears to be an Emacs bug, an unfortunate
- interaction between undo and process filters; the same problem exists in
- non-Python process buffers using the default (Emacs-supplied) process
- filter.
-
  @VARIABLES

  py-indent-offset\tindentation increment
--- 1064,1069 ----
***************
*** 1397,1418 ****
    (make-temp-name
     (concat (file-name-as-directory py-temp-directory) "python")))

! ;; pass a mixture of strings and lists of strings
! (defun py-delete-files-silently (&rest args)
!   (let (onearg)
!     (while args
!       (setq onearg (car args)
!         args (cdr args))
!       (if (stringp onearg) (setq onearg (list onearg)))
!       (while onearg
!     (condition-case nil
!         (delete-file (car onearg))
!       (error nil))
!     (setq onearg (cdr onearg))))))

  (defun py-kill-emacs-hook ()
    ;; delete our temp files
!   (py-delete-files-silently py-active-file py-pending-files)
    ;; run the hook we inherited, if any
    (and py-inherited-kill-emacs-hook
         (funcall py-inherited-kill-emacs-hook)))
--- 1396,1411 ----
    (make-temp-name
     (concat (file-name-as-directory py-temp-directory) "python")))

! (defun py-delete-file-silently (fname)
!   (condition-case nil
!       (delete-file fname)
!     (error nil)))

  (defun py-kill-emacs-hook ()
    ;; delete our temp files
!   (while py-file-queue
!     (py-delete-file-silently (car py-file-queue))
!     (setq py-file-queue (cdr py-file-queue)))
    ;; run the hook we inherited, if any
    (and py-inherited-kill-emacs-hook
         (funcall py-inherited-kill-emacs-hook)))

>>> END OF MSG










Received: from uvaarpa.Virginia.EDU by charon.cwi.nl with SMTP
    id AA26529 (5.65b/2.9/CWI-Amsterdam); Tue, 7 Apr 1992 05:51:51 +0200
Received: from uvacs.cs.virginia.edu by uvaarpa.Virginia.EDU id aa07319;
          6 Apr 92 23:51 EDT
Received: from wilbury.cs.Virginia.EDU by uvacs.cs.Virginia.EDU (4.1/5.1.UVA)
    id AA14348; Mon, 6 Apr 92 23:51:21 EDT
Posted-Date: Mon, 6 Apr 92 23:51:21 EDT
Return-Path: <[e-mail]>
Received: by wilbury.cs.Virginia.EDU (4.1/SMI-2.0)
    id AA01176; Mon, 6 Apr 92 23:51:21 EDT
Date: Mon, 6 Apr 92 23:51:21 EDT
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: unsubscribe



Thanks, but someone else at my sight is already on this mailing list.
Best to give the bandwidth to someone else. :)

                    Matt











Replied: Wed, 08 Apr 1992 09:55:19 +0200
Replied: "[e-mail] (Mats Lidell TM/JUF 91753) [e-mail]"
Received: from mailgate.ericsson.se by charon.cwi.nl with SMTP
    id AA21045 (5.65b/2.10/CWI-Amsterdam); Wed, 8 Apr 1992 00:05:13 +0200
Received: from juno (juno.ericsson.se) by mailgate.ericsson.se (4.1/SMI-4.1-MAILGATE1.10)
    id AA12367; Wed, 8 Apr 92 00:05:09 +0200
Received: by juno (4.1/SMI-4.1-LME1.6)
    id AA10855; Wed, 8 Apr 92 00:05:06 +0200
Date: Wed, 8 Apr 92 00:05:06 +0200
From: [e-mail] (Mats Lidell TM/JUF 91753)
Message-Id: <9204072205.AA10855@juno>
To: Guido van Rossum <[e-mail]>
Cc: [e-mail]
Subject: Python release 0.9.6 is here!
In-Reply-To: <[e-mail]>
References: <[e-mail]>

>>>>> "Guido" == Guido van Rossum <[e-mail]> writes:

  Guido> You are encouraged to port this to your system and report any
  Guido> problems you have.

OOPS! This happens to me. (I'm on a sun4 using sun vanilla cc. No
extra features selected for python.)

% dbx python
Reading symbolic information...
Read 17176 symbols
(dbx) run
Running: python
Python 0.9.6 (>= 1 Jan 1992).
Copyright 1990, 1991, 1992 Stichting Mathematisch Centrum, Amsterdam
>>> import testall
test_grammar
attempt to read stack failed - bad frame pointer
(dbx) where
_doprnt() at 0xf76e4ff4
attempt to read stack failed - bad frame pointer

%% Mats










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA12634 (5.65b/2.10/CWI-Amsterdam); Wed, 8 Apr 1992 09:55:21 +0200
Received: by voorn.cwi.nl with SMTP; Wed, 8 Apr 1992 07:55:21 GMT
Message-Id: <[e-mail]>
To: [e-mail] (Mats Lidell TM/JUF 91753)
Cc: [e-mail]
Subject: Re: Python release 0.9.6 is here!
In-Reply-To: Your message of "Wed, 08 Apr 1992 00:05:06 MDT."
             <9204072205.AA10855@juno>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Wed, 08 Apr 1992 09:55:20 +0200
Sender: [e-mail]

>OOPS! This happens to me. (I'm on a sun4 using sun vanilla cc. No
>extra features selected for python.)
>[dbx session transcript deleted]

Could it be that you have set your stacksize limit too low?  By doing
"limit stacksize 10" I can force Python to dump core, for instance.
A limit of 100 seems to be sufficient to run the tests, at least.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"That was never five minutes just now!"
"I'm afraid it was."










Replied: Thu, 09 Apr 1992 10:02:17 +0200
Replied: "[e-mail] (Patrick Dussud) [e-mail]"
Received: from lucid.com by charon.cwi.nl with SMTP
    id AA24312 (5.65b/2.10/CWI-Amsterdam); Wed, 8 Apr 1992 17:55:46 +0200
Received: from aspen.lucid (aspen.lucid.com) by heavens-gate.lucid.com id AA25249g; Wed, 8 Apr 92 08:49:19 PDT
Received: by aspen.lucid (4.1/SMI-4.1)
    id AA12736; Wed, 8 Apr 92 08:55:35 PDT
Date: Wed, 8 Apr 92 08:55:35 PDT
From: [e-mail] (Patrick Dussud)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Problem with (KeyboardInterrupt and wdb


Here is a problem that I found:
python dumps core if I use wdb and type ^C:

aspen% python
Python 0.9.6 (>= 1 Jan 1992).
Copyright 1990, 1991, 1992 Stichting Mathematisch Centrum, Amsterdam
>>> import sys
>>> sys.path.append ('../demo/scripts')
>>> import wdb
>>> wdb.run ('import pi')
31415926535897932384626433832Segmentation fault (core dumped)

                             ^C right here


Below is what I found out under gdb:

Program received signal 11, Segmentation fault
Reading symbols from ceval.c...done.
eval_code (co=(codeobject *) 0xa61f0, globals=(struct _object *) 0xa3df0, locals=(struct _object *) 0xe3aa0, arg=(struct _object *) 0xe3a60) (ceval.c:778)
(gdb) p w
$1 = (struct _object *) 0x0
(gdb) info loc
ticker = 94
next_instr = (unsigned char *) 0xa5cab "Z\002"
opcode = 92
oparg = 1
stack_pointer = (struct _object **) 0xe4884
why = WHY_NOT
err = 0
x = (struct _object *) 0x7f528
v = (struct _object *) 0xe3d80
w = (struct _object *) 0x0
u = (struct _object *) 0x0
t = (struct _object *) 0x7f528
f = (struct _frame *) 0xe4820
trace = (struct _object *) 0x0
retval = (struct _object *) 0xa3248
name = (char *) 0xc28cc "stopframe"
fp = (struct _iobuf *) 0x1a
(gdb) bt
#0  eval_code (co=(codeobject *) 0xa61f0, globals=(struct _object *) 0xa3df0, locals=(struct _object *) 0xe3aa0, arg=(struct _object *) 0xe3a60) (ceval.c:778)
#1  call_function (func=(struct _object *) 0xcd4e0, arg=(struct _object *) 0xe3a60) (ceval.c:1689)
#2  call_object (func=(struct _object *) 0xe3980, arg=(struct _object *) 0xe3a20) (ceval.c:1589)
#3  eval_code (co=(codeobject *) 0xc2680, globals=(struct _object *) 0xc1060, locals=(struct _object *) 0xe43e0, arg=(struct _object *) 0xe43a0) (ceval.c:385)
#4  call_function (func=(struct _object *) 0xc9e40, arg=(struct _object *) 0xe43a0) (ceval.c:1689)
#5  call_object (func=(struct _object *) 0xe3be0, arg=(struct _object *) 0xe3ec0) (ceval.c:1589)
#6  eval_code (co=(codeobject *) 0xbca60, globals=(struct _object *) 0xc1060, locals=(struct _object *) 0xe3e80, arg=(struct _object *) 0xe3e40) (ceval.c:385)
#7  call_function (func=(struct _object *) 0xc9e20, arg=(struct _object *) 0xe3e40) (ceval.c:1689)
#8  call_object (func=(struct _object *) 0xe3f60, arg=(struct _object *) 0xe3dc0) (ceval.c:1589)
#9  call_trace (p_trace=(struct _object **) 0xf7fff024, p_newtrace=(struct _object **) 0xf7fff024, f=(struct _frame *) 0xd6260, msg=(char *) 0x7acb4 "exception", arg=(struct _object *) 0xe3d80) (ceval.c:1247)
#10 call_exc_trace (p_trace=(struct _object **) 0xf7fff024, p_newtrace=(struct _object **) 0xf7fff024, f=(struct _frame *) 0xd6260) (ceval.c:1199)
#11 eval_code (co=(codeobject *) 0xd4ac0, globals=(struct _object *) 0x9a770, locals=(struct _object *) 0x9a770, arg=(struct _object *) 0x0) (ceval.c:1066)
#12 eval_node ()
#13 run_err_node ()
#14 run_string ()
#15 exec_eval ()
#16 builtin_exec ()
#17 call_builtin (func=(struct _object *) 0x98ff0, arg=(struct _object *) 0xd45c0) (ceval.c:1609)
#18 call_object (func=(struct _object *) 0x98ff0, arg=(struct _object *) 0xd45c0) (ceval.c:1591)
#19 eval_code (co=(codeobject *) 0xc7560, globals=(struct _object *) 0xc1060, locals=(struct _object *) 0xd5720, arg=(struct _object *) 0xd56e0) (ceval.c:385)
#20 call_function (func=(struct _object *) 0xca020, arg=(struct _object *) 0xd56e0) (ceval.c:1689)
#21 call_object (func=(struct _object *) 0xd5540, arg=(struct _object *) 0xd5640) (ceval.c:1589)
#22 eval_code (co=(codeobject *) 0xc7040, globals=(struct _object *) 0xc1060, locals=(struct _object *) 0xd5600, arg=(struct _object *) 0xd55c0) (ceval.c:385)
#23 call_function (func=(struct _object *) 0xca000, arg=(struct _object *) 0xd55c0) (ceval.c:1689)
#24 call_object (func=(struct _object *) 0xd4e40, arg=(struct _object *) 0xd4e60) (ceval.c:1589)
#25 eval_code (co=(codeobject *) 0xac050, globals=(struct _object *) 0xa3df0, locals=(struct _object *) 0xd5260, arg=(struct _object *) 0xd5220) (ceval.c:385)
#26 call_function (func=(struct _object *) 0xcaa80, arg=(struct _object *) 0xd5220) (ceval.c:1689)
#27 call_object (func=(struct _object *) 0xcaa80, arg=(struct _object *) 0xd5220) (ceval.c:1589)
#28 eval_code (co=(codeobject *) 0xd4800, globals=(struct _object *) 0x9a770, locals=(struct _object *) 0x9a770, arg=(struct _object *) 0x0) (ceval.c:385)
#29 eval_node ()
#30 run_tty_1 ()
#31 run_tty_loop ()
#32 main ()
(gdb) p *(tupleobject*)v
$6 = {ob_refcnt = 10, ob_type = 0x804f8, ob_size = 3, ob_item = {0x99430}}

(gdb) p ((tupleobject*)v)->ob_item[0]
$8 = (struct _object *) 0x99430
(gdb) p ((tupleobject*)v)->ob_item[1]
$9 = (struct _object *) 0x0

ob_item [1] is 0 so w becomes 0

(gdb) p ((tupleobject*)v)->ob_item[2]
$10 = (struct _object *) 0xe3d40











Received: from uvaarpa.Virginia.EDU by charon.cwi.nl with SMTP
    id AA24739 (5.65b/2.10/CWI-Amsterdam); Wed, 8 Apr 1992 18:08:09 +0200
Received: from uvacs.cs.virginia.edu by uvaarpa.Virginia.EDU id aa29683;
          8 Apr 92 12:07 EDT
Received: from ash.cs.Virginia.EDU by uvacs.cs.Virginia.EDU (4.1/5.1.UVA)
    id AA24206; Wed, 8 Apr 92 12:07:38 EDT
Posted-Date: Wed, 8 Apr 92 12:07:37 EDT
Return-Path: <[e-mail]>
Received: by ash.cs.Virginia.EDU (4.1/SMI-2.0)
    id AA04932; Wed, 8 Apr 92 12:07:37 EDT
Date: Wed, 8 Apr 92 12:07:37 EDT
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Python 0.9.6 and SPARCs

I'm having problems getting the new Python to work on
the SPARCstations here. Specifically, when I do a floating
point multiplication or divide Python core dumps. The dbx trace
doesn't help, as I just get garbage, usually with some mention of a
shared library.

It works fine on the SGIs.

I've tried using both cc and gcc to no avail.

Is there something I have to do to the Makefile or strtod.c?
(and if yours works, could you please send me your version?)

Thanks,
Steve










Received: from uvaarpa.Virginia.EDU by charon.cwi.nl with SMTP
    id AA25393 (5.65b/2.10/CWI-Amsterdam); Wed, 8 Apr 1992 18:26:42 +0200
Received: from uvacs.cs.virginia.edu by uvaarpa.Virginia.EDU id aa01005;
          8 Apr 92 12:25 EDT
Received: from ash.cs.Virginia.EDU by uvacs.cs.Virginia.EDU (4.1/5.1.UVA)
    id AA25370; Wed, 8 Apr 92 12:25:57 EDT
Posted-Date: Wed, 8 Apr 92 12:25:56 EDT
Return-Path: <[e-mail]>
Received: by ash.cs.Virginia.EDU (4.1/SMI-2.0)
    id AA05254; Wed, 8 Apr 92 12:25:56 EDT
Date: Wed, 8 Apr 92 12:25:56 EDT
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: SPARC problem fixed

OK, I solved the problem by cleverly reading lines in the makefile
that mention strtod isn't needed under SunOS 4. In fact, if you
include them, Python crashes.

Steve










Received: from lucid.com by charon.cwi.nl with SMTP
    id AA01577 (5.65b/2.10/CWI-Amsterdam); Wed, 8 Apr 1992 23:10:42 +0200
Received: from aspen.lucid (aspen.lucid.com) by heavens-gate.lucid.com id AA26295g; Wed, 8 Apr 92 14:04:24 PDT
Received: by aspen.lucid (4.1/SMI-4.1)
    id AA13134; Wed, 8 Apr 92 14:10:40 PDT
Date: Wed, 8 Apr 92 14:10:40 PDT
From: [e-mail] (Patrick Dussud)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: small bug in posixpath.py


def samestat(s1, s2):
    return s1[stat.ST_INO] == s2[stat.ST_INO] and \
        s1[stat.ST_DEV] == s2[stat.ST_DEV]
                                           ^^ not STD_DEV










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA18497 (5.65b/2.10/CWI-Amsterdam); Thu, 9 Apr 1992 10:02:36 +0200
Received: by voorn.cwi.nl with SMTP; Thu, 9 Apr 1992 08:02:21 GMT
Message-Id: <[e-mail]>
To: [e-mail] (Patrick Dussud)
Cc: [e-mail]
Subject: Re: Problem with (KeyboardInterrupt and wdb
In-Reply-To: Your message of "Wed, 08 Apr 1992 08:55:35 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 09 Apr 1992 10:02:20 +0200
Sender: [e-mail]

Patrick Dussud reported a Python core dump when a program being traced
by wdb or pdb is interrupted.  In private e-mail he suggested a fix.
Here's my version of that fix.  Note that this isn't an official patch
to Python, just a little band-aid if you're worried about it...

*** /tmp/,RCSt1a09915    Thu Apr  9 09:47:21 1992
--- ceval.c    Thu Apr  9 09:45:03 1992
***************
*** 1189,1194 ****
--- 1189,1198 ----
      object *type, *value, *traceback, *arg;
      int err;
      err_get(&type, &value);
+     if (value == NULL) {
+         value = None;
+         INCREF(value);
+     }
      traceback = tb_fetch();
      arg = newtupleobject(3);
      if (arg == NULL)

Hats off to Patrick for finding and solving this so quickly!

BTW, just in case anyone missed it, it is now official that on a Sparc
     DON'T USE THE STRTOD.C SOURCE DISTRIBUTED WITH PYTHON!

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I've got a pet halibut called Eric.  I chose him out of thousands,
the others were all to flat."










Received: from albert.gnu.ai.mit.edu by charon.cwi.nl with SMTP
    id AA20348 (5.65b/2.10/CWI-Amsterdam); Sat, 11 Apr 1992 08:45:27 +0200
Received: from hal.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
    id <[e-mail]>; Sat, 11 Apr 92 02:45:22 -0400
Received: by hal.gnu.ai.mit.edu (AIX 3.2/UCB 5.64/4.0)
    id <[e-mail]>; Sat, 11 Apr 1992 02:45:20 -0400
From: [e-mail]
Message-Id: <[e-mail]>
Subject: Request for list
To: [e-mail]
Date: Sat, 11 Apr 92 2:45:20 EDT

This is my request for the python list.
Here's the info you requested

Name: Craig Struble
E-mail: [e-mail]

    Thanks,
        Craig
--
     OOP : When people object to your orientation towards programming...
Craig Struble                            | [e-mail]
Consciousness increases development time | [e-mail]
A/UX Hacker Wannabe :-o                  | [e-mail] (SLIP)










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA04716 (5.65b/2.10/CWI-Amsterdam); Thu, 16 Apr 1992 11:05:30 +0200
Received: by voorn.cwi.nl with SMTP; Thu, 16 Apr 1992 09:05:29 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: comments please!
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 16 Apr 1992 11:05:27 +0200
Sender: [e-mail]

I am trying to get ready to post the complete Python sources to
comp.sources.unix (or somewhere else if the c.s.u moderators don't
accept it) so I can finally bump the version number to 1.0.  There
may be one round of patches posted to this mailing list first, to
correct minor things; this will create version 0.9.7.

The main think I'm currently worried about is the documentation.  If
you have comments, either very detailed or on the general structure
and quality, please let me know!  Of course, any other comments are
also welcome, but the point is that if the software doesn't work, I
get complaints immediately, while if there's a problem with the docs,
most people will figure it out anyway...

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Are all your pets called Eric?"










Replied: Fri, 17 Apr 1992 16:23:57 +0200
Replied: "[e-mail] [e-mail]"
Received: from albert.gnu.ai.mit.edu by charon.cwi.nl with SMTP
    id AA17985 (5.65b/2.10/CWI-Amsterdam); Thu, 16 Apr 1992 20:57:31 +0200
Received: from hal.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP
    id <[e-mail]>; Thu, 16 Apr 92 14:57:24 -0400
Received: by hal.gnu.ai.mit.edu (AIX 3.2/UCB 5.64/4.0)
    id <[e-mail]>; Thu, 16 Apr 1992 14:57:21 -0400
From: [e-mail]
Message-Id: <[e-mail]>
Subject: Bug in 0.9.6
To: [e-mail]
Date: Thu, 16 Apr 92 14:57:20 EDT

The only thing I've noticed so far is the use of the finally: clause. The
documentation states that a finally: clause needs to be placed after all
except statements, but python 0.9.6 won't accept a finally: clause at all if
except statements exist. For example, you can have:
    try:
        code...
    except:
        more code...

or
    try:
        code...
    finally:
        more code...

but not
    try:
        code...
    except:
        more code...
    finally:
        even more code...

This bug, or misfeature showed up when trying to run the python.py script.
Since I've just joined this group, I'm not sure if this bug has already
been reported. If this is a repeat bug, sorry.
    See ya later,
        Craig
--
                                Huh?
Craig Struble                            | [e-mail]
Consciousness increases development time | [e-mail]
A/UX Hacker Wannabe :-o                  | [e-mail] (SLIP)










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA17017 (5.65b/2.10/CWI-Amsterdam); Fri, 17 Apr 1992 16:24:01 +0200
Received: by voorn.cwi.nl with SMTP; Fri, 17 Apr 1992 14:24:00 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Bug in 0.9.6
In-Reply-To: Your message of "Thu, 16 Apr 1992 14:57:20 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 17 Apr 1992 16:24:00 +0200
Sender: [e-mail]

>The only thing I've noticed so far is the use of the finally: clause. The
>documentation states that a finally: clause needs to be placed after all
>except statements, but python 0.9.6 won't accept a finally: clause at all if
>except statements exist.

This was a last-minute change to the grammar; in the previous version
a try clause could have both except clauses and a finally clause; in
the new version it can have only one of the two kinds.  The reason for
the change is that it is both easier to explain and easier to
implement this way, and that the combination is rarely needed anyway.

I must admit that I haven't tried the python.py script for a long time
(since the Emacs python-mode.el has similar functionality); I'll fix
it for the next release.

Where in the docs did you see the old situation described?  I'm pretty
sure the reference manual describes the new version.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"It has ceased to be"










Received: from lucid.com by charon.cwi.nl with SMTP
    id AA02895 (5.65b/2.10/CWI-Amsterdam); Tue, 12 May 1992 18:07:21 +0200
Received: from aspen.lucid (aspen.lucid.com) by heavens-gate.lucid.com id AA14008g; Tue, 12 May 92 08:59:46 PDT
Received: by aspen.lucid (4.1/SMI-4.1)
    id AA03288; Tue, 12 May 92 09:05:36 PDT
Date: Tue, 12 May 92 09:05:36 PDT
From: [e-mail] (Patrick Dussud)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: MSDOS version of python


Someone I know would like to get an executable version of python for an MSDOS
machine, but I don't think we have a decent MSDOS compiler around here. Can
someone give me a pointer to an MSDOS version of python?
Thanks,
Patrick.










Replied: Tue, 19 May 1992 15:05:50 +0200
Replied: " [e-mail]"
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA25659 (5.65b/2.10/CWI-Amsterdam); Tue, 19 May 1992 09:44:56 +0200
Received: by voorn.cwi.nl with SMTP; Tue, 19 May 1992 07:44:56 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: MS-DOS Python binary available
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 19 May 1992 09:44:54 +0200
Sender: [e-mail]

Thanks to Mark Anacker I can now offer a binary of Python 0.9.6
compiled for MS-DOS computers.

You can ftp it from ftp.cwi.nl:/pub/python.exe.Z; use (UNIX)
uncompress to turn it into a PC binary and then transfer to the PC
using your favorite file transfer method.

If you want to use the standard Python library, you'll also have to
transfer the contents of the "lib" subdirectory of the Python source
distribution to your PC.

(Note that I am totally ignorant about PC things -- if there's a
better way to set things up, please let me know!)

Thanks, Mark!

--Guido










To: [e-mail]
Subject: MS-DOS Python binary available
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 19 May 1992 09:44:54 +0200
Sender: guido

Thanks to Mark Anacker I can now offer a binary of Python 0.9.6
compiled for MS-DOS computers.

You can ftp it from ftp.cwi.nl:/pub/python.exe.Z; use (UNIX)
uncompress to turn it into a PC binary and then transfer to the PC
using your favorite file transfer method.

If you want to use the standard Python library, you'll also have to
transfer the contents of the "lib" subdirectory of the Python source
distribution to your PC.

(Note that I am totally ignorant about PC things -- if there's a
better way to set things up, please let me know!)

Thanks, Mark!

--Guido










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA02291 (5.65b/2.10/CWI-Amsterdam); Tue, 19 May 1992 15:05:52 +0200
Received: by voorn.cwi.nl with SMTP; Tue, 19 May 1992 13:05:51 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: MS-DOS Python binary available
In-Reply-To: Your message of "Tue, 19 May 1992 09:44:54 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 19 May 1992 15:05:50 +0200
Sender: [e-mail]

A few hours ago I wrote:

>Thanks to Mark Anacker I can now offer a binary of Python 0.9.6
>compiled for MS-DOS computers.
>
>You can ftp it from ftp.cwi.nl:/pub/python.exe.Z [...]

I've since then located a copy of ZIP that works on UNIX.  Since ZIP
files are both smaller and more popular in the PC world, I've replaced
the python.exe.Z file by python0.9.6.zip.

As always, use binary ftp mode!

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Hello, I'm your new vicar.  Can I interest you in any encyclopaedias?"










cc: [e-mail]
Subject: Re: MS-DOS Python binary available
In-reply-to: Your message of "Tue, 19 May 1992 09:44:54 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 19 May 1992 15:05:50 +0200
Sender: guido

A few hours ago I wrote:

>Thanks to Mark Anacker I can now offer a binary of Python 0.9.6
>compiled for MS-DOS computers.
>
>You can ftp it from ftp.cwi.nl:/pub/python.exe.Z [...]

I've since then located a copy of ZIP that works on UNIX.  Since ZIP
files are both smaller and more popular in the PC world, I've replaced
the python.exe.Z file by python0.9.6.zip.

As always, use binary ftp mode!

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Hello, I'm your new vicar.  Can I interest you in any encyclopaedias?"










Received: from lucid.com by charon.cwi.nl with SMTP
    id AA04029 (5.65b/2.10/CWI-Amsterdam); Tue, 19 May 1992 16:33:03 +0200
Received: from aspen.lucid (aspen.lucid.com) by heavens-gate.lucid.com id AA18366g; Tue, 19 May 92 07:25:23 PDT
Received: by aspen.lucid (4.1/SMI-4.1)
    id AA16827; Tue, 19 May 92 07:32:56 PDT
Date: Tue, 19 May 92 07:32:56 PDT
From: [e-mail] (Patrick Dussud)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]> (message from Guido van Rossum on Tue, 19 May 1992 09:44:54 +0200)
Subject: MS-DOS Python binary available


Thanks Mark and Guido!
Patrick.










Received: from uvaarpa.Virginia.EDU by charon.cwi.nl with SMTP
    id AA08803 (5.65b/2.10/CWI-Amsterdam); Tue, 19 May 1992 20:29:07 +0200
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa16948;
          19 May 92 14:28 EDT
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA08215; Tue, 19 May 92 14:27:51 EDT
Date: Tue, 19 May 92 14:27:51 EDT
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: MS-DOS python


I started on compiling python for MS-DOS but have now
been moved to a Macintosh project, so I haven't had a
chance to get back to it.

I *did* need to truncate the "#include filename" filenames
to get anything to compile. [ With BORLAND C ]

Guido, here is the awk script I used, in case you want to fold it
into the distribution. Replaces all

#include longfilename.h    with:

#ifdef __MSDOS__
#include longfile.h
#else
#include longfilename.h
#endif

It doesn't try to do anything with "#include <filename>", but all of
those occurances seem to be short enough names.
It does not look like truncation produces any duplicate names.


/^#[ \t]*include[ \t]*"[A-Za-z0-9]*/     { \
        file = $2;
        n = split( file, a, "." );
        name = a[1];
        ext = a[2];
        if ( length( name ) < 10 )  {
          print ;
        }
        else {
          print "#ifdef __MSDOS__ ", "\t/*** Truncate file name ***/" ;
          print $1, substr(name,0,9) "."  ext;
          print "#else";
          print;
          print "#endif","\t/*** MSDOS *** Truncate file name ***/" ;
        }
       }
! /^#[ \t]*include[ \t]*"[A-Za-z0-9]*/      {  print  }




Was this step *not* needed with MSC ( or whatever was used ) ?

Any other tips/problems noted ?
[ Otherwise, I've been busy learning ( but not liking C++ ). ]


- Steve Majewski












Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA11959 (5.65b/2.10/CWI-Amsterdam); Wed, 20 May 1992 14:39:10 +0200
Received: by voorn.cwi.nl with SMTP; Wed, 20 May 1992 12:39:09 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Turbo C MS-DOS patches to Python
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Wed, 20 May 1992 14:39:09 +0200
Sender: [e-mail]

This is just a little note telling that Mark's patches for Python
0.9.6 to make it compile with Turbo C (Borland 2.0) under MS-DOS are
now available for anonymous ftp as

    ftp.cwi.nl:/pub/python-dos-patch

(Mark, do you have any interesting Python modules that use your pc
module?  Would you care to post them to the list as examples?)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Fear, surprise, ruthless efficiency, a fanatical devotion to the
pope, and nice red uniforms."










To: [e-mail]
Subject: Turbo C MS-DOS patches to Python
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Wed, 20 May 1992 14:39:09 +0200
Sender: guido

This is just a little note telling that Mark's patches for Python
0.9.6 to make it compile with Turbo C (Borland 2.0) under MS-DOS are
now available for anonymous ftp as

    ftp.cwi.nl:/pub/python-dos-patch

(Mark, do you have any interesting Python modules that use your pc
module?  Would you care to post them to the list as examples?)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Fear, surprise, ruthless efficiency, a fanatical devotion to the
pope, and nice red uniforms."










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA11959 (5.65b/2.10/CWI-Amsterdam); Wed, 20 May 1992 14:39:10 +0200
Received: by voorn.cwi.nl with SMTP; Wed, 20 May 1992 12:39:09 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Turbo C MS-DOS patches to Python
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Wed, 20 May 1992 14:39:09 +0200
Sender: [e-mail]

This is just a little note telling that Mark's patches for Python
0.9.6 to make it compile with Turbo C (Borland 2.0) under MS-DOS are
now available for anonymous ftp as

    ftp.cwi.nl:/pub/python-dos-patch

(Mark, do you have any interesting Python modules that use your pc
module?  Would you care to post them to the list as examples?)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Fear, surprise, ruthless efficiency, a fanatical devotion to the
pope, and nice red uniforms."










Received: from mcsun.EU.net by charon.cwi.nl with SMTP
    id AA20265 (5.65b/2.10/CWI-Amsterdam); Fri, 22 May 1992 03:19:45 +0200
Received: by mcsun.EU.net via EUnet
    id AA28112 (5.65b/CWI-2.162); Fri, 22 May 1992 03:19:42 +0200
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA28433; Thu, 21 May 92 21:18:23 -0400
Received: from amc-gw.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 211737.24503; Thu, 21 May 1992 21:17:37 EDT
Received: by amc-gw.amc.com (5.61/3.1.15/Ultrix-3.0)
    id AA06073; Thu, 21 May 92 09:20:26 -0700
Return-Path: <dsinet!marka>
Received: by dsinet.uucp (/\=-/\ Smail3.1.18.1 #18.22)
    id <[e-mail]>; Thu, 21 May 92 08:40 PDT
Message-Id: <[e-mail]>
From: [e-mail] (Mark Anacker)
Subject: MSDOS Python
To: [e-mail]
Date: Thu, 21 May 92 8:40:41 PDT
Mailer: Elm [revision: 64.9]

>
> This is just a little note telling that Mark's patches for Python
> 0.9.6 to make it compile with Turbo C (Borland 2.0) under MS-DOS are
> now available for anonymous ftp as
>
>       ftp.cwi.nl:/pub/python-dos-patch
>
> (Mark, do you have any interesting Python modules that use your pc
> module?  Would you care to post them to the list as examples?)

Actually, no. I have a lot of ideas, but right now it's more of a solution
in search of a problem :-)

To anyone who plans on using the pcmodule - I'm planning on totally revising
that module into three parts.  There will be a "pc" module that will have
Intel CPU functions (inp, outp, etc), a "bios" module that will have an
interface to all of the BIOS functions, and a "dos" module that will contain
MS-DOS functions.  Of course, programs using these won't port to anything
besides an IBM-PC clone, but they'll at least be there so you can play with
the system.

I'm also starting on making a PC version of the socket module, using the
Waterloo TCP libraries.  This one I want to make a duplicate of the unix
module, so socket-based programs will port straight across (well,
within reason - still no forks in MSDOS).

--
Mark Anacker                            ...{!dsinet,!toybox}!marka
Digital Systems International, Inc.     Redmond, WA   USA    [phone]
"We have a massive leadership vacuum in this country...
    and we need to change bags" - Sen. Belfry










To: [e-mail] (Kevin Samborn)
Subject: Re: please remove my name from this list
In-reply-to: Your message of "Thu, 21 May 1992 13:14:00 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 22 May 1992 08:28:23 +0200
Sender: guido

>I am leaving Sunrise to move back to my home town and get married...

Congratulations!  It has been nice talking to you...

>until then, please remove my name

Consider it done.

Cheers, stay in touch!

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"You're so *digital*, girl!" -- Neneh Cherry










Received: from lucid.com by charon.cwi.nl with SMTP
    id AA00899 (5.65b/2.10/CWI-Amsterdam); Fri, 22 May 1992 16:25:38 +0200
Received: from aspen.lucid (aspen.lucid.com) by heavens-gate.lucid.com id AA03069g; Fri, 22 May 92 07:17:50 PDT
Received: by aspen.lucid (4.1/SMI-4.1)
    id AA21409; Fri, 22 May 92 07:25:39 PDT
Date: Fri, 22 May 92 07:25:39 PDT
From: [e-mail] (Patrick Dussud)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]> ([e-mail])
Subject: MSDOS Python


By the way, did you try to run testall? A friend of mine says that the grammar
part never terminates on his machine.
Patrick.










Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA26085 (5.65b/2.10/CWI-Amsterdam); Fri, 26 Jun 1992 01:30:32 +0200
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: curses interface???
Date: Thu, 25 Jun 92 16:29:09 PDT
Message-Id:  <[e-mail]>

Has anyone created the necessary interfaces for a curses/forms/menus (a la AT&T)
interface?

Lance
[e-mail]










Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA26165 (5.65b/2.10/CWI-Amsterdam); Fri, 26 Jun 1992 01:31:47 +0200
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: Database interfaces
Date: Thu, 25 Jun 92 16:29:54 PDT
Message-Id:  <[e-mail]>

What database interfaces have people put together that they would be willing
to share?

Thanks,
Lance Ellinghouse
[e-mail]











Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA27990 (5.65b/2.10/CWI-Amsterdam); Fri, 26 Jun 1992 02:25:13 +0200
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: python ported to SCO UNIX?
Date: Thu, 25 Jun 92 17:23:35 PDT
Message-Id:  <[e-mail]>

Has anyone ported python to SCO UNIX?

Lance Ellinghouse
[e-mail]










Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA29721 (5.65b/2.10/CWI-Amsterdam); Fri, 26 Jun 1992 03:51:43 +0200
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: Re: Porting to SCO ODT
Date: Thu, 25 Jun 92 18:50:40 PDT
Message-Id:  <[e-mail]>

Got it to compile with minimal problems..
The tests cannot be run "out of the box" due
to 14 char truncation and things get overwritten with
comnpiled versions and such..

I have no idea if it is working correctly at this time.
I have to go rebuild the original versions of the tests,
then shorten their names and edit the testall.py file.

The only thing I really had to do was modify the Makefile
a little and socketmodule.c to remove the AF_UNIX
parts. (put an #ifdef and a define in the makefile
to skip them).

Lance
[e-mail]










Received: from math.waterloo.edu by charon.cwi.nl with SMTP
    id AA02257 (5.65b/2.10/CWI-Amsterdam); Fri, 26 Jun 1992 07:25:23 +0200
Received: from tslwat.uucp by math.waterloo.edu with uucp
    id <AA09719>; Fri, 26 Jun 92 01:25:12 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Thu, 25 Jun 92 22:02 EDT
Message-Id: <[e-mail]>
From: [e-mail] (Lou Kates)
Subject: deep copy
To: [e-mail]
Date: Thu, 25 Jun 92 22:02:53 EDT
X-Mailer: ELM [version 2.3 PL11]


Suppose a is  a list and we wish b  to have a copy of a such that
if a is later  modified b still  retains the original value of  a
that it had when it was copied.

>>> b = a

won't work since b just points to a; however,

>>> b = a[:]

seems to work  as  long as the   elements of a are not themselves
lists. In this last case even this does not work.

Is there some easy way to copy a into b as desired?

--
Lou Kates, [e-mail]










Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP
    id AA06711 (5.65b/2.10/CWI-Amsterdam); Fri, 26 Jun 1992 11:33:37 +0200
Received: by schelvis.cwi.nl with SMTP; Fri, 26 Jun 1992 09:33:36 GMT
Message-Id: <[e-mail]>
To: [e-mail] (Lou Kates)
Cc: [e-mail]
Subject: Re: deep copy
In-Reply-To: Message by [e-mail] (Lou Kates) ,
         Thu, 25 Jun 92 22:02:53 EDT , <[e-mail]>
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone](home)
X-Last-Band-Seen: Solid Ground (Korsakoff, 24-6)
X-Mini-Review: Solid and heavy.
Date: Fri, 26 Jun 1992 11:33:35 +0200
From: Jack Jansen <[e-mail]>

How about:
def deepcopy(p):
    if type(p) == type([]):
        p = p[:]
        for i in range(len(p)):
            p[i] = deepcopy(p[i])
    return p

This will copy lists and keep references to all other objects.
Extending it to also copy other mutable objects like dictionaries is
left as an excercise to the reader:-)

And, of course, Guido will probably post a much more elegant and
efficient solution:-)
--
Jack Jansen        | If I can't dance I don't want to be part of
[e-mail] | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA07185 (5.65b/2.10/CWI-Amsterdam); Fri, 26 Jun 1992 11:46:26 +0200
Received: by voorn.cwi.nl with SMTP; Fri, 26 Jun 1992 09:46:27 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: deep copy
From: Guido van Rossum <[e-mail]>
In-Reply-To: Your message of "Fri, 26 Jun 1992 11:33:35 MDT."
             <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 26 Jun 1992 11:46:26 +0200
Sender: [e-mail]

Jack posts a simple deepcopy() function for lists just like I would
have written it, and adds:

>And, of course, Guido will probably post a much more elegant and
>efficient solution:-)

No, I won't, since the problem is impossible to solve in full
generality.

A "simple" problems is how to treat objects that contain references to
themselves (maybe indirectly).  This can be solved by keeping a list
of all references encountered during the copying.  But what to do with
instances of user-defined classes, or worse, instances of opaque
built-in data types -- the latter may be defined by dynamically loaded
extension modules written in C, so you can't know in advance how to
handle them all.

Even types that you do know about beforehand can cause complications
-- how would you define a deep copy on an open file or a window object?

I must say that I can't remember that the general version of the
problem has ever come up in all the tens of thousands of lines of
Python code I've written -- one level of copying is usually
sufficient.  Lou, were you thinking of a particular application or
were you just trying to find out what the limits of the language are?

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Many of my best friends are lumberjacks and only a few of them are
transvestites"










Replied: Fri, 26 Jun 1992 14:13:58 +0200
Replied: "[e-mail] "
Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA09409 (5.65b/2.10/CWI-Amsterdam); Fri, 26 Jun 1992 13:46:22 +0200
Received: from stun4g.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA12658; Fri, 26 Jun 92 04:40:50 PDT
Date: Fri, 26 Jun 92 04:40:50 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4g.cs.caltech.edu (4.1/SMI-4.1)
    id AA12547; Fri, 26 Jun 92 04:46:20 PDT
To: [e-mail]
Subject: default environment setup

I would like to initialize a dictionary upon invocation of the python
interpreter . Is there a .python file ?

I am using the dictionary to index into the periodic table of elements
so that during the day instead of grunging through a textbook , I can
type

x = element['hydrogen']
print data_of[x]

where element = {'hydrogen':1, 'helium':2}

--
terrence brannon
[e-mail]











Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA09822 (5.65b/2.10/CWI-Amsterdam); Fri, 26 Jun 1992 14:13:58 +0200
Received: by voorn.cwi.nl with SMTP; Fri, 26 Jun 1992 12:14:00 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: default environment setup
In-Reply-To: Your message of "Fri, 26 Jun 1992 04:40:50 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 26 Jun 1992 14:13:59 +0200
Sender: [e-mail]

>I would like to initialize a dictionary upon invocation of the python
>interpreter . Is there a .python file ?

No, but you can simulate it by typing this at the first prompt:

>>> execfile('.python')

(This assumes the ".python" file is in the current directory.)

The Python interpreter does not automatically read a file of commands
because Python scripts should be independent of their environment, as
much as possible ($PYTHONPATH being the exception).

But if enough people want this, it's easy to add a feature whereby a
command line option (e.g. -f file) specifies a filename to be executed
before reading commands from stdin, or whereby an environment variable
(e.g. $PYTHONSTARTUP) specifies a file that is read by every
*interactive* interpreter.

Or are there any better ideas?

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"It's not much of a cheese shop really, is it?"










Replied: Fri, 26 Jun 1992 15:01:25 +0200
Replied: "[e-mail] "
Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA10341 (5.65b/2.10/CWI-Amsterdam); Fri, 26 Jun 1992 14:50:53 +0200
Received: from stun4g.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA12691; Fri, 26 Jun 92 05:45:20 PDT
Date: Fri, 26 Jun 92 05:45:20 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4g.cs.caltech.edu (4.1/SMI-4.1)
    id AA12551; Fri, 26 Jun 92 05:50:50 PDT
To: [e-mail]
Subject: although the manual states ...

------- Start of forwarded message -------
# this program

element = {'h': 1, 'he': 2, 'li':3, 'be':4, 'b':5}
print 'Atoms.py loaded and ready'

data = [ [0 , 0, '0'] , [1, 1.008, '1s1'] ,  [2, 4.003, '1s2'] ]


def lookup ( name ) :
    element[name]

print element
print data
fp = open('TEST', 'w')
try:
    fp.write(element)
    fp.write(data)

finally:
    fp.close()


# yield this output althought the manual states that lists and
# dictionaries are valid as long they are not recursive



Copyright 1990, 1991, 1992 Stichting Mathematisch Centrum, Amsterdam
>>> import mywrite
Atoms.py loaded and ready
{'he': 2, 'b': 5, 'h': 1, 'be': 4, 'li': 3}
[[0, 0, '0'], [1, 1.008, '1s1'], [2, 4.003, '1s2']]
TypeError: illegal argument type for built-in operation
Stack backtrace (innermost last):
  File "<stdin>", line 1
  File "./mywrite.py", line 14
    fp.write(element)
>>>
------- End of forwarded message -------










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA10424 (5.65b/2.10/CWI-Amsterdam); Fri, 26 Jun 1992 15:01:26 +0200
Received: by voorn.cwi.nl with SMTP; Fri, 26 Jun 1992 13:01:27 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: although the manual states ...
In-Reply-To: Your message of "Fri, 26 Jun 1992 05:45:20 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 26 Jun 1992 15:01:26 +0200
Sender: [e-mail]

Terrence M. Brannon complains that "fp.write()" does not accept
dictionaries and lists, even though the manual states that these can
be written unless recursive.

Unfortunately, this is the case only for the "print" statement, not
for the "write()" method of file objects -- the latter only accepts
strings.  To write non-string objects to a file, you can do two
things:

(1) temporarily assign the file object to sys.stdout and use print:

    >>> f = open(..., 'w')
    >>> import sys
    >>> save_stdout = sys.stdout
    >>> sys.stdout = f
    >>> print element
    >>> print data
    >>> sys.stdout = save_stdout

(2) convert the objects to a string using reverse quotes:

    >>> f = open(..., 'w')
    >>> f.write(`element`)
    >>> f.write('\n')
    >>> f.write(`data`)
    >>> f.write('\n')

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Look matey, this parrot wouldn't voom if I put four thousand volts
through it"










Replied: Mon, 29 Jun 1992 11:46:37 +0200
Replied: "python-list "
Replied: Mon, 29 Jun 1992 11:06:15 +0200
Replied: "[e-mail] "
Received: from math.waterloo.edu by charon.cwi.nl with SMTP
    id AA06851 (5.65b/2.10/CWI-Amsterdam); Sat, 27 Jun 1992 06:25:20 +0200
Received: from tslwat.uucp by math.waterloo.edu with uucp
    id <AA09522>; Sat, 27 Jun 92 00:25:08 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Fri, 26 Jun 92 23:19 EDT
Message-Id: <[e-mail]>
Date: Fri, 26 Jun 92 23:19 EDT
From: [e-mail] (Lou Kates)
To: [e-mail]
Subject: Re: deep copy


Forwarded message:
> From:    Guido van Rossum <[e-mail]>
>
> I must say that I can't remember that the general version of the
> problem has ever come up in all the tens of thousands of lines of
> Python code I've written -- one level of copying is usually
> sufficient.  Lou, were you thinking of a particular application or
> were you just trying to find out what the limits of the language are?
>

I was  working  on an  application which requires assigning (i.e.
deep copying) a two dimensional array  (i.e. a list of lists). As
an  aside,   it  also  requires  adding a  one dimensional  array
elementwise to a  one  dimensional  slice  of  a two  dimensional
array.

In general, my mindset is APL-ish here and I would like to assign
(i.e. deep copy) multi-dimensional arrays. (Actually I would like
to do  other  APL style  operations as well including elementwise
operations   such   as  addition   and  subtraction  on pairs  of
multidimensional, or at least one and two dimensional arrays.)

At least some of these  items (such as assigning multidimensional
arrays in a deep copy sense) seem as fundamental to me as strings
and dictionaries.

I assume that the applications you  refer to above were primarily
systems  software    oriented  whereas  I  am  referring more  to
mathematical,  statistical  and   data   processing     sorts  of
applications.

--
Lou Kates, [e-mail]











Replied: Mon, 29 Jun 1992 11:05:02 +0200
Replied: "Lance Ellinghouse <[e-mail]> "
Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA02058 (5.65b/2.10/CWI-Amsterdam); Sat, 27 Jun 1992 18:34:57 +0200
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: select
Date: Sat, 27 Jun 92 9:33:10 PDT
Message-Id:  <[e-mail]>

Has anyone created a select function similar to the select in BSD sockets?

I figured you could pass a list  of items in and have it return
a 3 element tupple of the return values..

Lance
[e-mail]










Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA02064 (5.65b/2.10/CWI-Amsterdam); Sat, 27 Jun 1992 18:38:04 +0200
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: Python...
Date: Sat, 27 Jun 92 9:36:25 PDT
Message-Id:  <[e-mail]>

What are people using python for in "real life"?
Any production usages?

I am thinking of using it for a project myself but cannot
decide between using Tcl or python. It will be a highly
interactive program that also needs to be resource conserving
because up to 64 people will be using it at once an a single
machine.

Thanks,
Lance Ellinghouse
[e-mail]

P.S. Please fogive if I ask some REALLY dump questions..











Received: from [138.95.19.12] by charon.cwi.nl with SMTP
    id AA22376 (5.65b/2.10/CWI-Amsterdam); Sun, 28 Jun 1992 23:03:26 +0200
Received: from eng2.sequent.com by gateway.sequent.com (5.61/1.34)
    id AA16849; Sun, 28 Jun 92 13:57:08 -0700
Received: by eng2.sequent.com (5.65/1.34)
    id AA09209; Sun, 28 Jun 92 13:58:58 -0700
Message-Id: <[e-mail]>
To: Lance Ellinghouse <[e-mail]>
Cc: [e-mail]
Subject: Re: select
Priority: Normal
Precedence: first-class
Organization: Sequent Computer Systems, Inc.
              Decision Support Group - MailStop: RHE2-358
          15450 S.W. Koll Parkway
              Beaverton, OR  97006
X-Phone: [phone]
X-Fax: [phone]
X-Uucp: ...!uunet!sequent!jaap
X-Internet: [e-mail]
X-Face: C4Cnai$>Eja5I6Vq?(gdN#SXX#`-XgAnmUn&e54sx7@1>q@vkrd_XnH![P>w.:7IJJ;{Bts
 WJd)u&G!V}0OR?2o5cUgIY}.T{g]PMC=*~]3n_t)S-ZkC(WG}3:#hcA6Oazx:}yc&k,hsF7D},7x>l
 nyfRjO7$@]fHBN>aC9-M3pKfbYHiy!PWD{_bx~fo})b4tU.;Ao%x[upCI,
In-Reply-To: Lance Ellinghouse's message of Sat, 27 Jun 92 09:33:10 -0700.
             <[e-mail]>
Date: Sun, 28 Jun 92 13:58:57 PDT
From: Jaap Vermeulen <[e-mail]>


| Has anyone created a select function similar to the select in BSD sockets?
|
| I figured you could pass a list  of items in and have it return
| a 3 element tupple of the return values..

Not yet, but I was thinking more in the direction of the poll() SYSV
system call.  It provides nicer semantics than the bitmask directed
select().

It would look like:

    file1 = open ('...', 'r')
    file2 = open ('...', 'r')
    timeout = 0

    filelist = select (((file1, 'r'), (file2, 'r')), timeout)

The input would be a list of (fileobject, string) pairs.  The string
would indicate 'r', 'w', 'e', or any permutation of those letters (for
read, write and exception; if you really want to confuse people you
could change the 'e' into an 'x' :-) :-).  The timeout would be in some
convenient timeformat with enough granularity to satisfy most needs
(tenth of seconds?).  If the timeout is 'None' the call would be
blocking.  It will return a list of (fileobject, string) pairs for
those fileobjects that have one or multiple events pending, or 'None'
if there are no pending events on any of the fileobjects.

If you have poll(), the implementation is quite straight-forward.  If
you only have select(), you have to construct the bitmasks from the
filelist information (which shouldn't be too hard).

Just my $0.02 worth.  Good luck,

    -Jaap-
--
Jaap Vermeulen                    +--------------------------+
                        | Sequent Computer Systems |
    Internet : [e-mail]        | Beaverton, Oregon       |
    Uucp     : ...uunet!sequent!jaap    +--------------------------+










Replied: Mon, 29 Jun 1992 11:12:38 +0200
Replied: "python-list "
Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA22727 (5.65b/2.10/CWI-Amsterdam); Sun, 28 Jun 1992 23:56:52 +0200
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: Re: select
Cc: [e-mail]
Date: Sun, 28 Jun 92 14:55:33 PDT
Message-Id:  <[e-mail]>

> | Has anyone created a select function similar to the select in BSD sockets?
> |
> | I figured you could pass a list  of items in and have it return
> | a 3 element tupple of the return values..
>
> Not yet, but I was thinking more in the direction of the poll() SYSV
> system call.  It provides nicer semantics than the bitmask directed
> select().
>
> It would look like:
>
>     file1 = open ('...', 'r')
>     file2 = open ('...', 'r')
>     timeout = 0
>
>     filelist = select (((file1, 'r'), (file2, 'r')), timeout)
>
> The input would be a list of (fileobject, string) pairs.  The string
> would indicate 'r', 'w', 'e', or any permutation of those letters (for
> read, write and exception; if you really want to confuse people you
> could change the 'e' into an 'x' :-) :-).

'e' sounds reasonable as does the layout of the call.
The question is how do you specify you wish to select/poll on it
for both reading and writing? Remember, sockets are bi-directional.
Or would you prefer that you do a sock.makefile('r') on it first?
Actually that seems like a nice solution to that. Forget the statement
above. I answered my own question.

> The timeout would be in some
> convenient timeformat with enough granularity to satisfy most needs
> (tenth of seconds?).  If the timeout is 'None' the call would be
> blocking.

I like that. But you should make it milliseconds since that is what
the select() and poll() actually take. (Although for the project I am
working on, I will probably only set it for 5-10 MINUTES :) )

> It will return a list of (fileobject, string) pairs for
> those fileobjects that have one or multiple events pending, or 'None'
> if there are no pending events on any of the fileobjects.

Sounds reasonable. Clean, clear, easy to parse return!

> If you have poll(), the implementation is quite straight-forward.  If
> you only have select(), you have to construct the bitmasks from the
> filelist information (which shouldn't be too hard).

The problem with poll() is that on some platforms, it handles
sockets, pipes, and files differently than select(). But I think
that the C code should be able to select which one you wish
to use via a #define statement when you do the compile.

Lance Ellinghouse
[e-mail]











Received: from [138.95.19.12] by charon.cwi.nl with SMTP
    id AA25422 (5.65b/2.10/CWI-Amsterdam); Mon, 29 Jun 1992 00:15:27 +0200
Received: from eng2.sequent.com by gateway.sequent.com (5.61/1.34)
    id AA18536; Sun, 28 Jun 92 15:13:31 -0700
Received: by eng2.sequent.com (5.65/1.34)
    id AA09779; Sun, 28 Jun 92 15:15:22 -0700
Message-Id: <[e-mail]>
To: Lance Ellinghouse <[e-mail]>
Cc: [e-mail]
Subject: Re: select
Priority: Normal
Precedence: first-class
Organization: Sequent Computer Systems, Inc.
              Decision Support Group - MailStop: RHE2-358
          15450 S.W. Koll Parkway
              Beaverton, OR  97006
X-Phone: [phone]
X-Fax: [phone]
X-Uucp: ...!uunet!sequent!jaap
X-Internet: [e-mail]
X-Face: C4Cnai$>Eja5I6Vq?(gdN#SXX#`-XgAnmUn&e54sx7@1>q@vkrd_XnH![P>w.:7IJJ;{Bts
 WJd)u&G!V}0OR?2o5cUgIY}.T{g]PMC=*~]3n_t)S-ZkC(WG}3:#hcA6Oazx:}yc&k,hsF7D},7x>l
 nyfRjO7$@]fHBN>aC9-M3pKfbYHiy!PWD{_bx~fo})b4tU.;Ao%x[upCI,
In-Reply-To: Lance Ellinghouse's message of Sun, 28 Jun 92 14:55:33 -0700.
             <[e-mail]>
Date: Sun, 28 Jun 92 15:15:21 PDT
From: Jaap Vermeulen <[e-mail]>


| > The input would be a list of (fileobject, string) pairs.  The string
| > would indicate 'r', 'w', 'e', or any permutation of those letters (for
| > read, write and exception; if you really want to confuse people you
| > could change the 'e' into an 'x' :-) :-).
|
| 'e' sounds reasonable as does the layout of the call.
| The question is how do you specify you wish to select/poll on it
| for both reading and writing? Remember, sockets are bi-directional.

If 'it' is opened for reading and writing, just specify the string 'rw'.

| Or would you prefer that you do a sock.makefile('r') on it first?
| Actually that seems like a nice solution to that. Forget the statement
| above. I answered my own question.

Correct, for sockets you have to create file fileobject before being able
to select on it.

| I like that. But you should make it milliseconds since that is what
| the select() and poll() actually take. (Although for the project I am
| working on, I will probably only set it for 5-10 MINUTES :) )

The question is not what the underlying system call can handle, the
question is what makes sense from python's point of view.  :-)  If
anybody ever needs millisecond granularity, sure, use that.  However I
doubt that it is useful...

| The problem with poll() is that on some platforms, it handles
| sockets, pipes, and files differently than select(). But I think
| that the C code should be able to select which one you wish
| to use via a #define statement when you do the compile.

Well, I assumed the select() semantics.  That is, you can select on
anything (if possible; as you point out some systems have
limitations).  If you don't select for an exception, and an exception
occurs for one of the fileobjects, you get a python error back
(probably with the value EBADF).  Note that this is different from the
sysV poll() system call semantics...

    -Jaap-
--
Jaap Vermeulen                    +--------------------------+
                        | Sequent Computer Systems |
    Internet : [e-mail]        | Beaverton, Oregon       |
    Uucp     : ...uunet!sequent!jaap    +--------------------------+










Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP
    id AA11133 (5.65b/2.10/CWI-Amsterdam); Mon, 29 Jun 1992 10:47:58 +0200
Received: by schelvis.cwi.nl with SMTP; Mon, 29 Jun 1992 08:47:57 GMT
Message-Id: <[e-mail]>
To: Lance Ellinghouse <[e-mail]>
Cc: [e-mail]
Subject: Re: Python...
In-Reply-To: Message by Lance Ellinghouse <[e-mail]> ,
         Sat, 27 Jun 92 9:36:25 PDT , <[e-mail]>
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone](home)
X-Last-Band-Seen: Kevin Coyne (Vondelpark, 28-6)
X-Mini-Review: Good! He does not look too healthy in the sun, though...
Date: Mon, 29 Jun 1992 10:47:57 +0200
From: Jack Jansen <[e-mail]>

Well, here at CWI we use python for *many* real life projects. Cmifed,
our multi-media document editor, is written completely in python. It
is about 10K lines, so that should probably make it the biggest python
program around as well.

There's also meeting, a network audio conferencing program, and
various tools to capture, playback and edit audio and video.

Besides those there's lots of utilities like an audible mail-warner (a
different sample played for everyone who sends you mail), some helper
programs for the ethernet radio stuff, etc.
--
Jack Jansen        | If I can't dance I don't want to be part of
[e-mail] | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA11480 (5.65b/2.10/CWI-Amsterdam); Mon, 29 Jun 1992 11:06:14 +0200
Received: by voorn.cwi.nl with SMTP; Mon, 29 Jun 1992 09:06:16 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: select
In-Reply-To: Your message of "Sat, 27 Jun 1992 09:33:10 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 29 Jun 1992 11:06:15 +0200
Sender: [e-mail]

>Has anyone created a select function similar to the select in BSD sockets?
>
>I figured you could pass a list  of items in and have it return
>a 3 element tupple of the return values..

What a coincidence!  About a week ago Jack and I sat together and
designed an interface for BSD select, and Jack made an implementation
of it.  The interface is like this:

    import select
    (ready_r, ready_w, ready_e) = \
        select.select(test_r, test_w, test_e, timeout)

Here test_r, test_w and test_e are lists of file or socket objects
(actually, anything with a 'fileno' method that returns a file
descriptor is possible; alternately, you may specify file descriptors
directly) and ready_{r,w,e} are similar lists containing the subset of
items from the corresponding test_* lists that are ready within the
timeout.  The timeout is a floating point number in seconds (so you
can specify any fraction you like and the system will round it to the
available precision).  Leaving the timeout parameter out means an
infinite time-out.

I can post or mail the patches if you like; it requires changes to
socketmodule.c and fileobject.c to add 'fileno()' methods to them.

I read the discussion on this list about an alternate design; while
that is also elegant I don't think the difference is important enough
to change the interface now that it's already been implemented...

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Rule six -- there is *no* rule six"

[Sorry Lance -- I accidentally mailed you a private copy of this...]










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA11517 (5.65b/2.10/CWI-Amsterdam); Mon, 29 Jun 1992 11:12:40 +0200
Received: by voorn.cwi.nl with SMTP; Mon, 29 Jun 1992 09:12:41 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: select
In-Reply-To: Your message of "Sun, 28 Jun 1992 14:55:33 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 29 Jun 1992 11:12:41 +0200
Sender: [e-mail]

(See also my previous message where I explain that Jack Jansen has
just created a BSD select interface.)

>The question is how do you specify you wish to select/poll on it
>for both reading and writing? Remember, sockets are bi-directional.

I'd say specify it twice, once for reading and once for writing.  This
works with Jack's implementation.  Or is there a limitation to poll
that makes this impossible?

>I like that. But you should make it milliseconds since that is what
>the select() and poll() actually take. (Although for the project I am
>working on, I will probably only set it for 5-10 MINUTES :) )

The standard solution in Python for this is floating point.  I still
want to change the time.sleep() function to accept a floating point
number so I can get rid of the separate time.millisleep() function --
the module time predates the existence of floating point in Python...

>The problem with poll() is that on some platforms, it handles
>sockets, pipes, and files differently than select(). But I think
>that the C code should be able to select which one you wish
>to use via a #define statement when you do the compile.

In the event that I or someone else may have to create an
implementation of Jack's select.select() using SYSV poll(), can you
(or another SYSV guru) enlighten me as to the nature of these
differences?

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"What a senseless waste of human life"










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA11964 (5.65b/2.10/CWI-Amsterdam); Mon, 29 Jun 1992 11:46:38 +0200
Received: by voorn.cwi.nl with SMTP; Mon, 29 Jun 1992 09:46:40 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: deep copy
In-Reply-To: Your message of "Fri, 26 Jun 1992 23:19:00 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 29 Jun 1992 11:46:39 +0200
Sender: [e-mail]

>I was  working  on an  application which requires assigning (i.e.
>deep copying) a two dimensional array  (i.e. a list of lists). As
>an  aside,   it  also  requires  adding a  one dimensional  array
>elementwise to a  one  dimensional  slice  of  a two  dimensional
>array.
>
>In general, my mindset is APL-ish here and I would like to assign
>(i.e. deep copy) multi-dimensional arrays. (Actually I would like
>to do  other  APL style  operations as well including elementwise
>operations   such   as  addition   and  subtraction  on pairs  of
>multidimensional, or at least one and two dimensional arrays.)
>
>At least some of these  items (such as assigning multidimensional
>arrays in a deep copy sense) seem as fundamental to me as strings
>and dictionaries.
>
>I assume that the applications you  refer to above were primarily
>systems  software    oriented  whereas  I  am  referring more  to
>mathematical,  statistical  and   data   processing     sorts  of
>applications.

Yes, I'm afraid that's the general mindset from which Python
originated.  If you really need a lot of 2-or-more dimensional array
operations you may be better off adding a new type to the language.
The type could use the interface style used by dictionaries (the
general term being "mappings") and it could define additional methods
for slice operations.  Buzz, buzz, whirr, whirr (thinking aloud :-)
you might use it as follows:

>>> import matrix
>>> m = matrix.new(10, 10, 0.0) # Create a 10x10 matrix initialized with zeros
>>> print m.dim()
(10, 10)
>>> print m.keys()
[(0, 0), (0, 1), ..., (0, 9), (1, 0), (1, 1), ..., (9, 9)]
>>> for i in range(m.dim()[0]): m[i, i] = 1.0
>>> for row, col in m.keys(): print row, col, m[row, col]
0 0 1.0
0 1 0.0
.
.
.
9 9 1.0
>>> m2 = m # Usual pointer copy -- m2 is the same object as m
>>> m3 = m.copy() # creates a new object -- elements are still shared
>>> m4 = m.slice((0, 10), (5, 10)) # creates a new object
                                   # containing rows [0..10), cols [5, 10)
>>> print m4.dim()
(10, 5)
>>> print m4.keys()
[(0, 0), (0, 1), ..., (0, 4), (1, 0), (1, 1), ..., (9, 4)]
>>> # Note how the indexes always start at 0 (point of discussion though)
>>> m.setslice((0, 10), (0, 5), m4) # Copy right half (m4) to left half

Vector extracted from a matrix are lists:

>>> v1 = m.row(0)
>>> print v1
[1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
>>> v2 = m.col(1)
>>> v3 = m.vec(0, 2) # same as m.row(2)
>>> v4 = m.vec(1, 3) # same as m.col(3)
>>> m.setrow(4, v3)
>>> m.setcol(5, v4)
>>> m.setvec(0, 6, v1)
>>> m.setvec(1, 7, v2)

Dot and other products are simply added.

I'm not sure what needs to be generalized to make this work for higher
dimensional arrays.  Sparse arrays are another matter.  One
interface would make references to non-existing elements illegal, and
require the user to use keys() or has_key() to figure out whether an
element exists; another interface would keep the sparseness internal
to the implementation and return a default value.

Note that there is no reason why elements of matrixes should be
numbers, except when they are used by numerical operations.

The language currently makes it hard to support element-wise addition
etc. using the standard notation (m1+m2 etc.) but it might evolve --
although + is already defined for lists to mean concatenation.

Other ideas?

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"It's not much of a cheese shop really, is it?"










Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP
    id AA13791 (5.65b/2.10/CWI-Amsterdam); Mon, 29 Jun 1992 13:46:36 +0200
Received: by schelvis.cwi.nl with SMTP; Mon, 29 Jun 1992 11:46:35 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Database interface to python
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone](home)
X-Last-Band-Seen: Kevin Coyne (Vondelpark, 28-6)
X-Mini-Review: Good! He does not look too healthy in the sun, though...
Date: Mon, 29 Jun 1992 13:46:34 +0200
From: Jack Jansen <[e-mail]>

Somebody asked for a database interface for python recently, and since
I had a spare afternoon (and wanted the exercise anyway:-) I made a
python interface to the unix ndbm(3) database library. The interface
is a mapping type, so you use it just as if dbm databases were python
dictionaries (except for opening the database, of course). I'll mail
it out if anyone is interested.
--
Jack Jansen        | If I can't dance I don't want to be part of
[e-mail] | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Replied: Mon, 29 Jun 1992 15:55:40 +0200
Replied: "python-list "
Received: from math.waterloo.edu by charon.cwi.nl with SMTP
    id AA15620 (5.65b/2.10/CWI-Amsterdam); Mon, 29 Jun 1992 15:26:51 +0200
Received: from tslwat.uucp by math.waterloo.edu with uucp
    id <AA00701>; Mon, 29 Jun 92 09:26:38 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Mon, 29 Jun 92 08:19 EDT
Message-Id: <[e-mail]>
Date: Mon, 29 Jun 92 08:19 EDT
From: [e-mail] (Lou Kates)
To: [e-mail]
Subject: range()
Cc: [e-mail]


In Python, you currently have to say:

    for i in range(len(a)-1,-1,-1):

to iterate backwards over the indices  of a list. Range should be
defined so that you can simply say:

    for i in range(len(a),0,-1):

If k>0, this could be done by defining

    range(m,n,-k)

to be equivalent to

    range(n,m,k).reverse()

That is to say, if the third  argument is negative then the range
that is  produced includes the second argument but not the first.
If the third argument  is positive  the range includes the  first
argument but not the second as is currently the case.


Lou Kates, [e-mail]










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA16097 (5.65b/2.10/CWI-Amsterdam); Mon, 29 Jun 1992 15:55:44 +0200
Received: by voorn.cwi.nl with SMTP; Mon, 29 Jun 1992 13:55:42 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: range()
In-Reply-To: Your message of "Mon, 29 Jun 1992 08:19:00 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 29 Jun 1992 15:55:41 +0200
Sender: [e-mail]

>In Python, you currently have to say:
>
>    for i in range(len(a)-1,-1,-1):
>
>to iterate backwards over the indices  of a list. Range should be
>defined so that you can simply say:
>
>    for i in range(len(a),0,-1):
>
>If k>0, this could be done by defining
>
>    range(m,n,-k)
>
>to be equivalent to
>
>    range(n,m,k).reverse()
>
>That is to say, if the third  argument is negative then the range
>that is  produced includes the second argument but not the first.
>If the third argument  is positive  the range includes the  first
>argument but not the second as is currently the case.

Interesting suggestion; at first I thought I'd agree with you
completely (barring backward compatibility, which I don't think will
be a big problem); but what about things like range(0, -5, -1)?
Currently this returns [0, -1, -2, -3, -4]; under Lou's proposed
definition it would change to [-1, -2, -3, -4, -5].  Intimate lovers
of two's complement arithmetic might expect that, but to me it feels
slightly uneasy.

Any other opinions?

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"This is an ex-parrot"










Replied: Tue, 30 Jun 1992 10:50:16 +0200
Replied: "[e-mail] "
Received: from math.waterloo.edu by charon.cwi.nl with SMTP
    id AA10315 (5.65b/2.10/CWI-Amsterdam); Tue, 30 Jun 1992 04:24:53 +0200
Received: from tslwat.uucp by math.waterloo.edu with uucp
    id <AA13152>; Mon, 29 Jun 92 22:24:49 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Mon, 29 Jun 92 21:33 EDT
Message-Id: <[e-mail]>
From: [e-mail] (Lou Kates)
Subject: Re: range() (fwd)
To: [e-mail]
Date: Mon, 29 Jun 92 21:33:11 EDT
X-Mailer: ELM [version 2.3 PL11]

Forwarded message:
> Sender: [e-mail]
>
> >In Python, you currently have to say:
> >
> >    for i in range(len(a)-1,-1,-1):
> >
> >to iterate backwards over the indices  of a list. Range should be
> >defined so that you can simply say:
> >
> >    for i in range(len(a),0,-1):
> >
> >If k>0, this could be done by defining
> >
> >    range(m,n,-k)
> >
> >to be equivalent to
> >
> >    range(n,m,k).reverse()
> >
> >That is to say, if the third  argument is negative then the range
> >that is  produced includes the second argument but not the first.
> >If the third argument  is positive  the range includes the  first
> >argument but not the second as is currently the case.
>
> Interesting suggestion; at first I thought I'd agree with you
> completely (barring backward compatibility, which I don't think will
> be a big problem); but what about things like range(0, -5, -1)?
> Currently this returns [0, -1, -2, -3, -4]; under Lou's proposed
> definition it would change to [-1, -2, -3, -4, -5].  Intimate lovers
> of two's complement arithmetic might expect that, but to me it feels
> slightly uneasy.
>
> Any other opinions?
>
> --Guido van Rossum, CWI, Amsterdam <[e-mail]>
> "This is an ex-parrot"
>


You make  an interesting  point. I   would like to expand on  it.
Suppose s is  scalar and v is a list regarded  as a vector. As in
usual vector arithmetic define s * v to be the list, i.e. vector,
whose i-th element is s * v[i].

Then the existing range() function in Python enjoys the following
pleasing proportionality property:

    s * range(m, n, k) = range(s * m, s * n, s * k)

for all non-zero values of s including negative values.

The definition  that I  had proposed  is the same as the existing
range() for positive steps and  by definition obeys the following
identity which allows it to be extended to negative steps:

    range(m, n, -k) = range(n, m, k).reverse()

With the   existing range(),  the formula   for s * range() as  a
range()  is   simple   even   if   s<0  but    the   formula  for
range().reverse() as a range() is complex.

In my  proposed  formula, the  formula for range().reverse() as a
range() is simple but the formula for  s * range() as a range  is
complex if s<0.

Its a  judgement call as to  whether range() should behave nicely
under proportionality or  reversal since it appears that it won't
behave nicely under both.

I have to admit that I  prefer the proportionality identity which
means that range() would stay as it is.

Getting back  to the  original example,  I guess the moral of the
story  is   that  if one   wants to  elegantly express  backwards
iteration over list indices one should use the idiom:

    for i in range(len(a)).reverse():

Lou

P.S. Note how   the  above   discussion required APL-like  vector
     multiplication to state the proportionality property even in
     this apparently not heavily mathematical setting!

--
Lou Kates, [e-mail]










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA16726 (5.65b/2.10/CWI-Amsterdam); Tue, 30 Jun 1992 10:50:17 +0200
Received: by voorn.cwi.nl with SMTP; Tue, 30 Jun 1992 08:50:18 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: range() (fwd)
In-Reply-To: Your message of "Mon, 29 Jun 1992 21:33:11 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 30 Jun 1992 10:50:17 +0200
Sender: [e-mail]

Lou Kates writes:

>Its a  judgement call as to  whether range() should behave nicely
>under proportionality or  reversal since it appears that it won't
>behave nicely under both.
>
>I have to admit that I  prefer the proportionality identity which
>means that range() would stay as it is.

Well, the law of the least hassle also suggests that it should stay
that way, unless someone else will start a major upraising...

>Getting back  to the  original example,  I guess the moral of the
>story  is   that  if one   wants to  elegantly express  backwards
>iteration over list indices one should use the idiom:
>
>    for i in range(len(a)).reverse():

Unfortunately, list.reverse() is a procedure (== function returning
None) that has a side effect (reversing the list in place) and does
not return a value, so in real current Python you have to write:

    tmp = range(len(a))
    tmp.reverse()
    for i in tmp: ...

In general, Python procedures can't be changed to functions without
breaking existing code since the interpreter prints the value of an
expression-statement if it isn't otherwise used.  If this were deemed
useful enough it would be easy to add a method list.reversed() that
would return a reversed copy.  For consistency we would then also need
a list.sorted() method.

>P.S. Note how   the  above   discussion required APL-like  vector
>     multiplication to state the proportionality property even in
>     this apparently not heavily mathematical setting!

"Required" seems a bit strong here, especially from someone who has
already admitted he's got an APL mindset. :-)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"It happens sometimes -- people just explode.  Natural causes."










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA21135 (5.65b/2.10/CWI-Amsterdam); Tue, 30 Jun 1992 14:08:32 +0200
Received: by voorn.cwi.nl with SMTP; Tue, 30 Jun 1992 12:08:32 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: dbm and select modules available
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 30 Jun 1992 14:08:31 +0200
Sender: [e-mail]

On popular demand I've made the 'dbm' and 'select' modules available
for anonymous ftp.

Host: ftp.cwi.nl
Directory: pub
File: python-dbm-select

It's a shar file containing some patches and new source files.

(Note that this is not a release of Python 0.9.7; it's a set of
temporary patches for those who asked for them.)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
Founder of the Royal Society for Prevention of Cruelty to Amoebae










Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA29544 (5.65b/2.10/CWI-Amsterdam); Tue, 30 Jun 1992 20:53:12 +0200
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: Submitted files and such..
Date: Tue, 30 Jun 92 11:53:33 PDT
Message-Id:  <[e-mail]>

For those submitting files and such (now and in the future)
can you please keep in mind that some of us have machines that
only support 14 char file names...
The posted python-ndbm-select file contains a number of files that
I have to pull apart by hand due to the length of the file names.

Thank you,
Lance Ellinghouse
[e-mail]











Replied: Wed, 01 Jul 1992 10:40:52 +0200
Replied: Lance Ellinghouse <[e-mail]>
Replied: [e-mail]
Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA17661 (5.65b/2.10/CWI-Amsterdam); Wed, 1 Jul 1992 03:59:13 +0200
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: selectmodule.c & mkvalue()
Date: Tue, 30 Jun 92 19:00:13 PDT
Message-Id:  <[e-mail]>

the recently posted socketmodule.c uses a routine (mkvalue())
that is not defined anywhere.. Could the person that created
socketmodule.c please post mkvalue() also?

Thank you,
Lance Ellinghouse
[e-mail]










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA24397 (5.65b/2.10/CWI-Amsterdam); Wed, 1 Jul 1992 10:40:46 +0200
Received: by voorn.cwi.nl with SMTP; Wed, 1 Jul 1992 08:40:50 GMT
Message-Id: <[e-mail]>
To: Lance Ellinghouse <[e-mail]>
Cc: [e-mail]
Subject: Re: selectmodule.c & mkvalue()
In-Reply-To: Your message of "Tue, 30 Jun 1992 19:00:13 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Wed, 01 Jul 1992 10:40:49 +0200
Sender: [e-mail]

>the recently posted socketmodule.c uses a routine (mkvalue())
>that is not defined anywhere.. Could the person that created
>socketmodule.c please post mkvalue() also?

Oops, it's in a new version of modsupport.c.  I've put that on the ftp
site as well (just the file).  You must add a declaration for
mkvalue() to modsupport.h: "object *mkvalue();" will do.

BTW, I apologize for the less than professional way in which these
mods are distributed.  It's really time that I send out an entire new
version of the system (0.9.7) but that takes much more time -- I want
to avoid the kind of mistakes in a real distribution that I made now :-)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
PS: do you save your mail without headers and signatures?










Replied: Thu, 02 Jul 1992 16:41:24 +0200
Replied: "[e-mail] (Terrence M. Brannon) [e-mail]"
Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA05285 (5.65b/2.10/CWI-Amsterdam); Thu, 2 Jul 1992 16:35:45 +0200
Received: from stun4r.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA26955; Thu, 2 Jul 92 07:35:29 PDT
Date: Thu, 2 Jul 92 07:35:29 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4r.cs.caltech.edu (4.1/SMI-4.1)
    id AA04130; Thu, 2 Jul 92 07:35:35 PDT
To: [e-mail]
Subject: HOw does one print without a c/r ?
Comments: Hyperbole mail buttons accepted, v3.02P.

Is it possible to print something but not automatically have a
carriage return appended to it ?

--
terrence brannon
[e-mail]











Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA05349 (5.65b/2.10/CWI-Amsterdam); Thu, 2 Jul 1992 16:41:23 +0200
Received: by voorn.cwi.nl with SMTP; Thu, 2 Jul 1992 14:41:26 GMT
Message-Id: <[e-mail]>
To: [e-mail] (Terrence M. Brannon)
Cc: [e-mail]
Subject: Re: HOw does one print without a c/r ?
In-Reply-To: Your message of "Thu, 02 Jul 1992 07:35:29 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 02 Jul 1992 16:41:25 +0200
Sender: [e-mail]

>Is it possible to print something but not automatically have a
>carriage return appended to it ?

Yes, append a comma after the last argument to print.  For instance,
this loop prints the numbers 0..9 on a line separated by spaces.  Note
the parameterless "print" that adds the final newline:

>>> for i in range(10):
...     print i,
... else:
...     print
...
0 1 2 3 4 5 6 7 8 9
>>>

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Is it a bird? No! Is it a plane? No! It's bicycle repair man!"










Replied: Thu, 02 Jul 1992 17:05:21 +0200
Replied: "python-list "
Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA05464 (5.65b/2.10/CWI-Amsterdam); Thu, 2 Jul 1992 16:54:34 +0200
Received: from stun4r.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA26984; Thu, 2 Jul 92 07:53:49 PDT
Date: Thu, 2 Jul 92 07:53:49 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4r.cs.caltech.edu (4.1/SMI-4.1)
    id AA04133; Thu, 2 Jul 92 07:53:55 PDT
To: [e-mail]
Subject: One Really Important Suggestion
Comments: Hyperbole mail buttons accepted, v3.02P.

NOt to be critical, but since python is an interpreted language , a
key asset of such a language would be to re-import modules and be able
to test the methods out that I just changed.

It would speed up incremental development much more if I did not have
to exit the interpreter each time I wanted to retest an altered
module.

However, I guess an alternate solution is to run the source from the
shell instead of import module and the module.method()

--
terrence brannon
[e-mail]











Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA05584 (5.65b/2.10/CWI-Amsterdam); Thu, 2 Jul 1992 17:05:20 +0200
Received: by voorn.cwi.nl with SMTP; Thu, 2 Jul 1992 15:05:23 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: One Really Important Suggestion
In-Reply-To: Your message of "Thu, 02 Jul 1992 07:53:49 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 02 Jul 1992 17:05:22 +0200
Sender: [e-mail]

>Not to be critical, but since python is an interpreted language , a
                                            ^^^^^^^^^^^
>key asset of such a language would be to re-import modules and be able
>to test the methods out that I just changed.

I suppose you meant "interactive" there?

>It would speed up incremental development much more if I did not have
>to exit the interpreter each time I wanted to retest an altered
>module.

You don't have to.  Look at the description of the built-in function
'reload()'.  There are some restrictions, but if you are working on a
single it is often what you need.

>However, I guess an alternate solution is to run the source from the
>shell instead of import module and the module.method()

If you have GNU Emacs, and are using the Python mode provided with the
Python distribution (misc/python-mode.el), you can use C-c C-c in a
Python buffer to run the current buffer through the interpreter.  You
can also start an interactive Python interpreter in another window
with C-c !; C-c C-c will then send the buffer as input to that
interpreter.  See the mode-specific info for more hints.

Finally, the '-c statements' command line option to the interpreter is
sometimes useful, especially if your shell has a fast way of repeating
the last command (e.g. csh '!!'  or ksh 'r').

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"It's a bit runny, sir"










Replied: Thu, 02 Jul 1992 22:48:58 +0200
Replied: [e-mail]
Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA11418 (5.65b/2.10/CWI-Amsterdam); Thu, 2 Jul 1992 22:18:08 +0200
Received: from stun4q.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA28196; Thu, 2 Jul 92 13:17:56 PDT
Date: Thu, 2 Jul 92 13:17:56 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4q.cs.caltech.edu (4.1/SMI-4.1)
    id AA12118; Thu, 2 Jul 92 13:18:02 PDT
To: [e-mail]
Subject: what is the 256 on my screen ?
Comments: Hyperbole mail buttons accepted, v3.02P.

i did an os.system() call and I keep getting thsse 256 or 0 on my
screen after the call . Is there anyway to nullify this output ?

i am starting up a faq for python by the way

--
terrence brannon
[e-mail]











Received: from [138.95.19.12] by charon.cwi.nl with SMTP
    id AA12043 (5.65b/2.10/CWI-Amsterdam); Thu, 2 Jul 1992 22:39:38 +0200
Received: from eng2.sequent.com by gateway.sequent.com (5.61/1.34)
    id AA15603; Thu, 2 Jul 92 13:37:38 -0700
Received: by eng2.sequent.com (5.65/1.34)
    id AA02958; Thu, 2 Jul 92 13:39:32 -0700
Message-Id: <[e-mail]>
To: [e-mail] (Terrence M. Brannon)
Cc: [e-mail]
Subject: Re: what is the 256 on my screen ?
Priority: Normal
Precedence: first-class
Organization: Sequent Computer Systems, Inc.
              Decision Support Group - MailStop: RHE2-358
          15450 S.W. Koll Parkway
              Beaverton, OR  97006
X-Phone: [phone]
X-Fax: [phone]
X-Uucp: ...!uunet!sequent!jaap
X-Internet: [e-mail]
X-Face: C4Cnai$>Eja5I6Vq?(gdN#SXX#`-XgAnmUn&e54sx7@1>q@vkrd_XnH![P>w.:7IJJ;{Bts
 WJd)u&G!V}0OR?2o5cUgIY}.T{g]PMC=*~]3n_t)S-ZkC(WG}3:#hcA6Oazx:}yc&k,hsF7D},7x>l
 nyfRjO7$@]fHBN>aC9-M3pKfbYHiy!PWD{_bx~fo})b4tU.;Ao%x[upCI,
In-Reply-To: Terrence M. Brannon's message of Thu, 02 Jul 92 13:17:56 -0700.
             <[e-mail]>
Date: Thu, 02 Jul 92 13:39:31 PDT
From: Jaap Vermeulen <[e-mail]>


| i did an os.system() call and I keep getting thsse 256 or 0 on my
| screen after the call . Is there anyway to nullify this output ?

It's the returned exitcode.  I guess you could use:

    None = os.system('...')

    -Jaap-
--
Jaap Vermeulen                    +--------------------------+
                        | Sequent Computer Systems |
    Internet : [e-mail]        | Beaverton, Oregon       |
    Uucp     : ...uunet!sequent!jaap    +--------------------------+










To: [e-mail]
Subject: Re: what is the 256 on my screen ?
In-reply-to: Your message of "Thu, 02 Jul 1992 13:17:56 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 02 Jul 1992 22:48:56 +0200
Sender: guido

[e-mail] (Terrence M. Brannon):
>i did an os.system() call and I keep getting thsse 256 or 0 on my
>screen after the call . Is there anyway to nullify this output ?

Yes.  This is the exit status of the command (really the return value
of system(3)).  The Python interpreter prints the value of an
expression statement unless it is None -- this is done so you can use
the interpreter as an interactive calculator.  The simplest way of
avoiding the printing of the value is to assign it to a dummy value.

>i am starting up a faq for python by the way

That's great.  Will it be ftp'able?  I might point new readers of the
list to it, to get them up at full speed quickly...

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Repo Man's got all night, *every* night"










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA12221 (5.65b/2.10/CWI-Amsterdam); Thu, 2 Jul 1992 22:48:55 +0200
Received: by voorn.cwi.nl with SMTP; Thu, 2 Jul 1992 20:48:57 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: what is the 256 on my screen ?
In-Reply-To: Your message of "Thu, 02 Jul 1992 13:17:56 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 02 Jul 1992 22:48:56 +0200
Sender: [e-mail]

[e-mail] (Terrence M. Brannon):
>i did an os.system() call and I keep getting thsse 256 or 0 on my
>screen after the call . Is there anyway to nullify this output ?

Yes.  This is the exit status of the command (really the return value
of system(3)).  The Python interpreter prints the value of an
expression statement unless it is None -- this is done so you can use
the interpreter as an interactive calculator.  The simplest way of
avoiding the printing of the value is to assign it to a dummy value.

>i am starting up a faq for python by the way

That's great.  Will it be ftp'able?  I might point new readers of the
list to it, to get them up at full speed quickly...

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Repo Man's got all night, *every* night"










Received: from hopscotch.ksr.com by charon.cwi.nl with SMTP
    id AA12423 (5.65b/2.10/CWI-Amsterdam); Thu, 2 Jul 1992 22:53:23 +0200
Received: from ksr.com (frankenstein.ksr.com) by hopscotch.ksr.com with SMTP
    id AA07013; Thu, 2 Jul 1992 16:52:24 -0400
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA04275; Thu, 2 Jul 92 16:53:10 EDT
Received: by kaos.ksr.com (4.0/KSR-2.0)
    id AA21371; Thu, 2 Jul 92 16:53:09 EDT
Message-Id: <[e-mail]>
To: [e-mail] (Terrence M. Brannon)
Subject: Re: what is the 256 on my screen ?
Cc: [e-mail]
Date: Thu, 02 Jul 92 16:53:07 -0400
From: Tim Peters <[e-mail]>

>  i did an os.system() call and I keep getting thsse 256 or 0 on my
>  screen after the call . Is there anyway to nullify this output ?
>
>  i am starting up a faq for python by the way

Well, since Python isn't Perl, when it does something you didn't expect
you can bet it did it for a rational reason <grin>.

Specifically, os.system(some_cmd) returns the exit status of `some_cmd',
and Python always prints the value of a statement that consists in its
entirety of a raw expression.  So the line

    os.system(some_cmd)

will always print the exit status of some_cmd, for exactly the same
reason that the line

    1+2

prints "3".  Try, e.g.,

    suppress_printing_exit_status = os.system(some_cmd)

That won't print the exit status, & for the same reason that

    a = 1+2

won't print "3".

Was that pedantic enough <grin>?

there's-always-a-sensible-method-to-guido's-fine-madness-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










Received: from [138.95.19.12] by charon.cwi.nl with SMTP
    id AA13673 (5.65b/2.10/CWI-Amsterdam); Thu, 2 Jul 1992 23:12:02 +0200
Received: from eng2.sequent.com by gateway.sequent.com (5.61/1.34)
    id AA16690; Thu, 2 Jul 92 14:10:01 -0700
Received: by eng2.sequent.com (5.65/1.34)
    id AA07452; Thu, 2 Jul 92 14:11:54 -0700
Message-Id: <[e-mail]>
To: [e-mail] (Terrence M. Brannon)
Cc: [e-mail]
Subject: [Jaap: Re: what is the 256 on my screen ?]
Priority: Normal
Precedence: first-class
Date: Thu, 02 Jul 92 14:11:53 PDT
From: Jaap Vermeulen <[e-mail]>


I said:

|It's the returned exitcode.  I guess you could use:
|
|    None = os.system('...')

Ah, that would redefine 'None', not what you want ... :-)

I thought it would just throw away the value that way (Guido, wouldn't
it be handy if there were a way to just discard a value?)

    -Jaap-










Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA15777 (5.65b/2.10/CWI-Amsterdam); Fri, 3 Jul 1992 00:03:53 +0200
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: FTP sites...
Date: Thu, 2 Jul 92 15:04:40 PDT
Message-Id:  <[e-mail]>

> >i am starting up a faq for python by the way
>
> That's great.  Will it be ftp'able?  I might point new readers of the
> list to it, to get them up at full speed quickly...

To make things easier, there needs to be an FTP archive site for
the latest versions of Python as well as additional modules,
FAQ, etc...

Does anyone want to set one up in the US? I would be happy to, but our bandwidth
it not very much (14.4K)...

Lance Ellinghouse
[e-mail]











Replied: Fri, 03 Jul 1992 11:07:54 +0200
Replied: "[e-mail] (Terrence M. Brannon) [e-mail]"
Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA21644 (5.65b/2.10/CWI-Amsterdam); Fri, 3 Jul 1992 01:32:54 +0200
Received: from stun4q.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA28413; Thu, 2 Jul 92 16:32:48 PDT
Date: Thu, 2 Jul 92 16:32:48 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4q.cs.caltech.edu (4.1/SMI-4.1)
    id AA12213; Thu, 2 Jul 92 16:32:55 PDT
To: [e-mail]
Subject: just out of curiosity...
Comments: Hyperbole mail buttons accepted, v3.02P.

TeX section headers have the following format:

\section{Using Nitroglycerin in the Home}

the following works:

#!/tmp/python

import os, string, sys , regex

sect_regex = regex.compile('^.*\\section{\(.+\)+}.*$')
def main():
    p = open(sys.argv[1] , 'r')
    total, d = None, {}
    for line in p.readlines():
    if (sect_regex.match(line) != -1):
        print line

main()


but changing the regex to
sect_regex = regex.compile('^\\section{\(.+\)+}.*$')

fails which implies that there is something at the front of the line
that I cannot see . any idea what?

--
terrence brannon
[e-mail]











Received: from goudvink.cwi.nl by charon.cwi.nl with SMTP
    id AA29815 (5.65b/2.10/CWI-Amsterdam); Fri, 3 Jul 1992 10:59:09 +0200
Received: by goudvink.cwi.nl with SMTP
    id AA19285 (5.65b/2.10/CWI-Amsterdam); Fri, 3 Jul 1992 10:59:07 +0200
Message-Id: <[e-mail]>
To: [e-mail] (Terrence M. Brannon)
Cc: [e-mail]
Subject: Re: just out of curiosity...
In-Reply-To: Your message of "Thu, 02 Jul 1992 16:32:48 PDT."
             <[e-mail]>
From: Jan-Hein Buhrman <[e-mail]>
X-Organization: CWI (Centre for Mathematics and Computer Science),
        Kruislaan 413, 1098 SJ  Amsterdam, The Netherlands
X-Phone: [phone] (work), +31 20 592.4199 (fax)
Date: Fri, 03 Jul 1992 10:59:05 +0200
Sender: [e-mail]

Terence M. Brannon <[e-mail]>:
>Target to search for is `\section{Using Nitroglycerin in the Home}',
>at the start of a line.
>
>sect_regex = regex.compile('^.*\\section{\(.+\)+}.*$') works, but
>sect_regex = regex.compile('^\\section{\(.+\)+}.*$') doesn't work.
I'm not a regular python user (that's an understatement), but I
recognize the type of confusion from Emacs' elisp programming.

For python, the string '\\' contains one (1) backslash (`\'). So
regexp.compile just sees the sequence `\sectio<...etc.>', and depending
on the kind of regexp library, mode, and program you are working with,
the backslash might be thrown away, generates an error, or means "match
a character whose syntax belongs to the code `e' (see Emacs syntax
codes)."

I tested the next part of code, and it works:

sect_regex = regex.compile('^\\\\section{\\(.+\\)}.*$')

Watch also the double backslashes before the braces. Hope this helps.

-- Jan-Hein Buhrman -- CWI, Amsterdam -- <[e-mail]> --
NFS server (amd:109) not responding still trying
NFS server (amd:109) ok
/ufs/jh/lib/mottos: No such file or directory










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA29953 (5.65b/2.10/CWI-Amsterdam); Fri, 3 Jul 1992 11:07:54 +0200
Received: by voorn.cwi.nl with SMTP; Fri, 3 Jul 1992 09:07:56 GMT
Message-Id: <[e-mail]>
To: [e-mail] (Terrence M. Brannon)
Cc: [e-mail]
Subject: Re: just out of curiosity...
In-Reply-To: Your message of "Thu, 02 Jul 1992 16:32:48 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 03 Jul 1992 11:07:55 +0200
Sender: [e-mail]

>sect_regex = regex.compile('^\\section{\(.+\)+}.*$')
>
>fails which implies that there is something at the front of the line
>that I cannot see . any idea what?

To include a literal backslash in a regular expression you must double
it, but to include one in a Python string literal you must also double
it.  As a consequence, you have to QUADRUPLE a literal backslash
included in a regular expression written as a Python string literal.

Now you may ask, "but the \( and \) worked just fine".  That is
because in Python string literals (and this is documented in the
reference manual!) a backslash followed by a character that isn't part
of one of the standard escape sequences (\n, \t, \ddd, etc. -- exactly
the same list as in Standard C) stays in the string.  As far as I know
the only character that has a special meaning following a backslash in
regular expressions as well as in Python string literals is the
backslash itself.

Call it a minor nuisance.  I'll add a note to the documentation of the
regex module.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"This is an ex-parrot"










To: [e-mail] (Terrence M. Brannon)
cc: [e-mail]
Subject: Re: just out of curiosity...
In-reply-to: Your message of "Thu, 02 Jul 1992 16:32:48 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 03 Jul 1992 11:07:55 +0200
Sender: guido

>sect_regex = regex.compile('^\\section{\(.+\)+}.*$')
>
>fails which implies that there is something at the front of the line
>that I cannot see . any idea what?

To include a literal backslash in a regular expression you must double
it, but to include one in a Python string literal you must also double
it.  As a consequence, you have to QUADRUPLE a literal backslash
included in a regular expression written as a Python string literal.

Now you may ask, "but the \( and \) worked just fine".  That is
because in Python string literals (and this is documented in the
reference manual!) a backslash followed by a character that isn't part
of one of the standard escape sequences (\n, \t, \ddd, etc. -- exactly
the same list as in Standard C) stays in the string.  As far as I know
the only character that has a special meaning following a backslash in
regular expressions as well as in Python string literals is the
backslash itself.

Call it a minor nuisance.  I'll add a note to the documentation of the
regex module.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"This is an ex-parrot"










Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA10317 (5.65b/2.10/CWI-Amsterdam); Fri, 3 Jul 1992 19:11:47 +0200
Received: from stun4b.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA00981; Fri, 3 Jul 92 10:11:25 PDT
Date: Fri, 3 Jul 92 10:11:25 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4b.cs.caltech.edu (4.1/SMI-4.1)
    id AA01933; Fri, 3 Jul 92 10:11:35 PDT
To: [e-mail]
Subject: Survey of Emacs Lisp, Perl, Python, and Tcl
Comments: Hyperbole mail buttons accepted, v3.02P.

Note: this is not the Python FAQ. I am working on that next.

The purpose of this FAQ is to expose people to several languages which
can cutdown/eliminate shell programming and C programming.

All of these languages are quick interpreted languages which can do
things in a few lines which might take hundreds of lines of C/shell
code.

I tried to be objective but I have not learned Perl. I looked into Perl
but gave it up - it seemed very odd to me.

Suggestions to Terrence Brannon <[e-mail]>.
E-mail [e-mail] for details about the League for Programming Freedom.


Overview
********


Emacs Lisp
==========
Anything Emacs does is done in Lisp, so you can do it to. But you can
only do it inside of Emacs Lisp for the most part. The two work arounds
are: (1) use emacs-server.el which allows Emacs to send/receive on
sockets (2) use emacs server mode. Both are rather hairy.

Cant call from C and cant call from the shell.


Perl
====
Combines the best features of awk, sed, and shell programming. The
latest version can be embedded in C programs. It is also easy to call
from the shell.


Python
======
An object-oriented interpreted language. Callable from C as well as the
shell. Interpretation may be sidestepped through the use of the
byte-compiler on files. Python played a major role in testing Amoeba, a
distributed operating system developed at CWI.


Tcl
===
Extremely strong in X-windows. It can do a 5 page x-windows program in
*2* lines and more. Callable from C and from the shell.


File: toolkit.languages.info  Node: Power, Prev: Overview, Up: Top, Next: Graphics

Power
*****

All of the systems will be evaluated in terms of their capabilities in
graphics, string handling, and process control. They will also be
evaluated in terms of their extensions.


File: toolkit.languages.info  Node: Graphics, Prev: Power, Up: Top, Next: String Handling

Graphics
========


Emacs Lisp
-----------
None internally, but the ability to spawn inferior unix
processes and issue shell commands allows it to use tcl's WAFE or fire
up a Python process and control it with ease.


Perl
----
Again none interally, but it might take the same route os Emacs Lisp but
my feeling is it would be a harder task than in Emacs Lisp.


Python
------
Through the use of the STDWIN paradigm, the same source code
can do graphics in the following systems:

  1. X-windows
  2. Macintosh
  3. Atari ST
  4. DOS
  5. Silicon Graphics SGI workstations

This approach allows flexibility but means that no one graphics system's
potential is maximized.


Tcl
---
Overloaded with all types of very very easy to do attractive
graphics in X-Windows only. Easy to learn, and has many nice widgets
added to it such as a photo widget for display of scanned PBM images,
a bar graph widget, an editable text widget and much more.
Powerful tcl-based graphics systems come to mind:

  1. VOGLE - 3D rendering, fonts
  2. BYO Interface Builder. A snap to use.
  3. WAFE . Send text string from anywhere (C language, Emacs, shell) to
     a server and have the graphics done for you.
  4. BOS - An object oriented extension for Tcl which also has some
     widgets added to it.


File: toolkit.languages.info  Node: String Handling, Prev: Graphics, Up: Top, Next: Process Control

String Handling
===============


Emacs Lisp
----------
Strong. Many good string handling functions for operation on buffers as
well as string. Search replace backward and forward with regexps. Many
good string handling functions are found in tree-dired.el in gmhist*.el.
As well as in ange-ftp.el.


Perl
----
Well, its a language optimized for this so it is good, but in some cases
the lack of complex data structures is a problem. For example, even
though Perl is becoming the tool of choice among system administrators,
Tom Christiansen, an expert Perl programmer makes note of how the lack
of complex data structures in Perl made a program to format the output
of du in a tree format exceedingly difficult. This same program was done
in Python in 50 lines.


Python
------
It has a string module and regexp module. It has all the string
*search* capabilities of Emacs, but since strings are immutable in
Python, it understandably does not have Emacs Lisp's string replace power.


Tcl
---
Everything in Tcl is a string. It is very easy to map certain
string-intensive applications to Tcl. For example, I wrote a program to
do parallel library database searches in Tcl in about two weeks. Ranking
the 4 languages in terms of how easy it would have been: Tcl, Python,
Emacs, and I cant say about Perl because I gave up on Perl quickly after
buying the book and seeing all those registers and the confusing
context-intensive syntax.



File: toolkit.languages.info  Node: Process Control, Prev: String Handling, Up: Top, Next: Extensions

Process Control
===============


Emacs Lisp
----------
Has specialized modes for controlling Common and other lisps to
facilitate debugging, execution, and programming. Has shell modes with
command history. Has an excellent ftp program (ange-ftp). Can
asynchronously or synchronously call the shell and store the output in a
buffer or string. Can filter output from a process. However, the
filtering is somewhat hairy because you cannot be sure of the packet
size that the data will arrive in. In other words, it is easy to open a
pipe with Perl/Python/Tcl and just read lines at a time but you have to
write an accumulator function to do this in Emacs Lisp. However, the
interactor mode for GNU Smalltalk has an excellent accumulator function
that you could use in your own code.


Perl
----
Chat2.pl .. I dont know


Python
------
You would use pipes to do this in Python. It would be as easy as Emacs,
however, so much is already written for Emacs. Python is a young
language with far less supporters.


Tcl
---
Even stronger than Emacs. A package by Don Libes called Expect allows
the programmer to specify a set of expected regexps from the process and
what to do upon the receipt of the process output. Several of his papers
including Expect: Programs for Controlling Interactive Processes are
available in postscript format for anonymous ftp from durer.cme.nist.giv
in pub/expect.


File: toolkit.languages.info  Node: Extensions, Prev: Process Control, Up: Top, Next: Documentation

Extensions
==========

An important feature of these languages is how much is already there for
you to use.


Emacs Lisp
----------
Emacs is light years ahead of any of these other languages in this respect.
  1. 4 mail readers (rmail, vm, mh-e, elm interface)
  2. 2 Usenet news readers (gnus, rnews+)
  3. Ange-FTP -- An excellent ftp utility which allows transparent
     file access/modification with the ease of a few keystrokes.
  4. Countless interfaces for everything from Archie to MUD.
  5. AUC-TeX allows you to do anything you would want to do with
     TeX/LaTeX from an Emacs buffer quickly and easily.
  6. Calc is a poor man's Mathematica
  7. VIP -- vi emulation for emacs
  8. Calendar/Diary -- calendar manager within Emacs
  9. Tree Dired -- better directory editor for Emacs
 10. Hyperbole -- extensible hypertext management system within Emacs
 11. Ispell -- spell checker in C with interface for Emacs
 12. Patch -- program to apply "diffs" for updating files

Emacs' use of switchable modes allows for easy creation of new packages
with their own set of keyboard macros or they can simply use a
predefined mode.


Perl
----
  1. chat2pl --


Python
------
  1. ?? -- Multimedia interface.
  2. ?? -- Remote Procedure Call debugger
  3. texfix -- Crude convert latex to texinfo
  4. throughput -- measure tcp throughput
  5. dutree -- format du(1) output at a tree sorted by size
  6. findlinks -- recursively find links to a given path prefix
  7. lpwatch -- watch BSD line printer queues
  8. suff -- sort a list of files by suffix


Tcl
===
  1. Basic Object System -- adds object oriented capabilities to Tcl. It is
     not class-based but prototype-based whatever that means.
  2. CD Rom Interface
  3. MXEdit -- Text editor
  4. tclTCP/rawTCP -- tcp/ip for tcl remote procedure calls and connect
     activity
  5. VOGLE -- awesome full-color 3-D rendering package with a ton of
     fonts, both american and foreign.

* Menu:


* Documentation::
* Top::



File: toolkit.languages.info  Node: Documentation, Prev: Extensions, Up: Top, Next: Ease of Use

Documentation
*************


Emacs Lisp
==========
Excellent. Both for using Emacs and programming Emacs Lisp.


Perl
====
Excellent. A book is out by Larry Wall called Programming in Perl. The
50-page man page is not bad.


Python
======
Good. Covers everything but how to extend Python through C.


Tcl
===
Good. The author of Tcl, John Ousterhout, will mail you the manual
pages.


File: toolkit.languages.info  Node: Ease of Use, Prev: Documentation, Up: Top, Next: Extensibility

Ease of Use
***********

Emacs Lisp
==========
The best. Has a debugger. Since you are in Emacs, you can immediately
test whatever you are writing. Documentation on every function and
variable in memory is available in 2 keypresses. The tags system allows
you to jump to functions and global variable declarations without
knowing which file they are in.

Perl
====
Ok. There is a Perl mode for Emacs.

Python
======
Good. You can send a buffer to a python interpreter by using Emacs.

Tcl
===
Ok. The language itself is straightforward. There is a tcl mode for
Emacs but nothing written to
allow you to send a buffer of code to the tcl interpreter. Development
is still pretty fast.


File: toolkit.languages.info  Node: Extensibility, Prev: Ease of Use, Up: Top, Next: Test Suite

Extensibility
*************


Emacs Lisp
==========
Writing new lisp functions is only feasible by using the
already-available lisp functions. To write new lisp functions in C would mean
re-compiling Emacs every time.


Perl
====
Very difficult.


Python
======
Its possible in Python and C. How to do it in C is not well documented.


Tcl
===
Its possible in Tcl and well-docuemented and has been down well by many
people in C.


File: toolkit.languages.info  Node: Test Suite, Prev: Top, Up: Top, Next: Top

Test Suite
**********


Emacs Lisp
==========
Well, if you compile Emacs then Emacs Lisp will run. This is
irrelevant criteria for Emacs Lisp.

Perl
====
Assorted programs here and there.

Python
======
Exhaustive test suite

Tcl
===
Exhaustive test suite












Received: from mail.unet.umn.edu by charon.cwi.nl with SMTP
    id AA12286 (5.65b/2.10/CWI-Amsterdam); Fri, 3 Jul 1992 22:15:10 +0200
Received: from s6.math.umn.edu by mail.unet.umn.edu (5.65c/)
    id AA05943; Fri, 3 Jul 1992 15:15:06 -0500
Date: Fri, 3 Jul 92 15:16:38 CDT
From: "Erik E. Rantapaa" <[e-mail]>
Message-Id: <[e-mail]>
Received: by s6.math.umn.edu; Fri, 3 Jul 92 15:16:38 CDT
To: [e-mail]
Subject: Survey of Emacs Lisp, Perl, Python, and Tcl (and Icon?)


[e-mail] (Terrence M. Brannon) writes:

>The purpose of this FAQ is to expose people to several languages which
>can cutdown/eliminate shell programming and C programming.

I would suggest adding Icon to your survey.  It runs on most Unix platforms,
can be interpreted or compiled, and has been used for a lot of the things
that shells scripts and Perl has been used for.

Unforunately I am not that experienced with using it so I can't give
you more particulars -- perhaps someone else can (or ask comp.lang.icon).










Replied: Sun, 05 Jul 1992 12:48:16 +0200
Replied: "[e-mail] (Terrence M. Brannon) "
Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA23413 (5.65b/2.10/CWI-Amsterdam); Sat, 4 Jul 1992 04:16:32 +0200
Received: from stun4r.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA01246; Fri, 3 Jul 92 19:16:12 PDT
Date: Fri, 3 Jul 92 19:16:12 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4r.cs.caltech.edu (4.1/SMI-4.1)
    id AA04421; Fri, 3 Jul 92 19:16:28 PDT
To: [e-mail]
Subject: 2 inter-related questions
Comments: Hyperbole mail buttons accepted, v3.02P.

( 1 )

Ok, since my python script requires argv[1], I have to call it from
the shell, right ? There is not way from the python interpreter to go:

>>> set shellProgramArgs = 'test2.c'
>>> exec 'compilify'

So that Python will issue compilify test2.c to the shell right ?


( 2 )

After I run a script from the shell , I sometimes would like to drop
into the interpreter to see the values of some things . Is there a
Python command to do this ?



See so basically what has happened is I cant use the python shell to
test values after running a program and I also cant let a script
running frm csh call the python shell after it has finished so I can
examine values.

( 3 )

os.popen execs its argument based on its own shell , not the one with
my PATH environmental variable . As a result , it cant find things
that are own my path that are not on the default PATH . Besides moving
the executable to the current directory or another place on the
default PATH, is there a workaround ?


Also : all of this is going into a FAQ sheet .


--
terrence brannon
[e-mail]











Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA14644 (5.65b/2.10/CWI-Amsterdam); Sun, 5 Jul 1992 12:49:18 +0200
Received: by voorn.cwi.nl with SMTP; Sun, 5 Jul 1992 10:49:21 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: 2 inter-related questions
In-Reply-To: Your message of "Fri, 03 Jul 1992 19:16:12 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Sun, 05 Jul 1992 12:49:20 +0200
Sender: [e-mail]

>Ok, since my python script requires argv[1], I have to call it from
>the shell, right ? There is not way from the python interpreter to go:
>
>>>> set shellProgramArgs = 'test2.c'
>>>> exec 'compilify'
>
>So that Python will issue compilify test2.c to the shell right ?

I have no idea what you want here -- it's totally un-Python syntax and
I don't know what 'compilify' is supposed to mean, but:

(a) a Python receives its arguments in sys.argv; you can interactively
import sys and assign anything you want to sys.argv.

(b) The 'os module defines an exec() function with the same
functionality as exec(2) in the C library.

(c) To run a Python script from an interactive Python interpreter, you
can either use the built-in function evalfile(), or (if the script's
file name ends in '.py') import it as a module.  The first time you
import a module its statements are executed -- this initializes the
module.  To re-run the statements in an imported module, use the
built-in function reload().

>( 2 )
>
>After I run a script from the shell , I sometimes would like to drop
>into the interpreter to see the values of some things . Is there a
>Python command to do this ?

No, but you can run the script from an interactive Python interpreter,
as explained above.

>See so basically what has happened is I cant use the python shell to
>test values after running a program and I also cant let a script
>running frm csh call the python shell after it has finished so I can
>examine values.

Again I don't know how to interpret your sentence, but maybe I've
answered it anyway?

>( 3 )
>
>os.popen execs its argument based on its own shell , not the one with
>my PATH environmental variable . As a result , it cant find things
>that are own my path that are not on the default PATH . Besides moving
>the executable to the current directory or another place on the
>default PATH, is there a workaround ?

Sounds like a problem in your C library -- on my system, popen
definitely sees my $PATH.  Are you sure you are exporting $PATH from
your shell?

>Also : all of this is going into a FAQ sheet .

Is this a threat? :-)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Kemal Ataturk had an entire menagerie called Abdul."










Received: from meermin.cwi.nl by charon.cwi.nl with SMTP
    id AA00230 (5.65b/2.10/CWI-Amsterdam); Sun, 5 Jul 1992 20:58:40 +0200
Received: from hopscotch.ksr.com by meermin.cwi.nl with SMTP
    id AA12345 (5.65a/2.10/CWI-Amsterdam); Sun, 5 Jul 1992 18:20:08 GMT
Received: from ksr.com (frankenstein.ksr.com) by hopscotch.ksr.com with SMTP
    id AA02093; Sun, 5 Jul 1992 14:18:09 -0400
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA28895; Sun, 5 Jul 92 14:19:03 EDT
Received: by kaos.ksr.com (4.0/KSR-2.0)
    id AA16047; Sun, 5 Jul 92 14:19:02 EDT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: 2 inter-related questions
Date: Sun, 05 Jul 92 14:19:02 -0400
From: Tim Peters <[e-mail]>

>>Ok, since my python script requires argv[1], I have to call it from
>>the shell, right ? There is not way from the python interpreter to go:
>>
>>>>> set shellProgramArgs = 'test2.c'
>>>> exec 'compilify'
>>
>>So that Python will issue compilify test2.c to the shell right ?

I'm not sure what you're after here either, but suspect the following
might do the trick.  Here's file "compilify":

#!/lang/users/tim/bin/python

import sys
print 'I think my name is', sys.argv[0]
print 'I think my arguments are', sys.argv[1:]

And here's an interpreter session:

>>> import os
>>> os.system('compilify test2.c')
I think my name is ./compilify
I think my arguments are ['test2.c']
0
>>>

Note that "0" was printed by the interpreter; it's the exit status of
the "system" call.  You can suppress that by assigning to a dummy vrbl,
like:

>>> dummy = os.system('compilify test2.c')
I think my name is ./compilify
I think my arguments are ['test2.c']
>>>

I doubt you really want the `os.exec' function, because that will
replace the interpreter with the thing being exec'ed.

As Guido mentioned, this will also do the trick (so long as the thing
you want to run from the interpreter is a Python script; 'system' and
'exec' can execute anything):

>>> import sys
>>> sys.argv = ['blah', 'test2.c']
>>> execfile('compilify')
I think my name is blah
I think my arguments are ['test2.c']
>>>

>>os.popen execs its argument based on its own shell , not the one with
>>my PATH environmental variable . As a result , it cant find things
>>that are own my path that are not on the default PATH . Besides moving
>>the executable to the current directory or another place on the
>>default PATH, is there a workaround ?

>[guido]
>Sounds like a problem in your C library -- on my system, popen
>definitely sees my $PATH.  Are you sure you are exporting $PATH from
>your shell?

I don't think I understood the original question -- an example would
sure help!

But no problems with $PATH here either.  I'll just add that if the thing
being popen'd is a Python script, it won't find $PATH in sys.path, but
in os.environ['PATH'].  I've seen Python beginners panic over that
before (they look at sys.path & figure their $PATH has been destroyed).

>>Also : all of this is going into a FAQ sheet .
>Is this a threat? :-)

no-but-this-is<grin>-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










Received: from ansjovis.cwi.nl by charon.cwi.nl with SMTP
    id AA18910 (5.65b/2.10/CWI-Amsterdam); Mon, 6 Jul 1992 10:45:07 +0200
Received: by ansjovis.cwi.nl with SMTP; Mon, 6 Jul 1992 08:45:06 GMT
Message-Id: <[e-mail]>
To: [e-mail] (Terrence M. Brannon)
Cc: [e-mail]
Subject: Re: Survey of Emacs Lisp, Perl, Python, and Tcl
In-Reply-To: Your message of Fri, 03 Jul 1992 10:11:25 -0700.
             <[e-mail]>
Date: Mon, 06 Jul 1992 10:45:05 +0200
From: Sjoerd Mullender <[e-mail]>

On Fri, Jul 3 1992 Terrence M. Brannon wrote:

> Python
> ======
> An object-oriented interpreted language. Callable from C as well as the
> shell. Interpretation may be sidestepped through the use of the
> byte-compiler on files. Python played a major role in testing Amoeba, a
> distributed operating system developed at CWI.

Amoeba existed long before Python.  It is true that Python was ported
to Amoeba (i.e. ran under Amoeba) and that the Amoeba primitives were
ported to Python, but is can hardly be said that "Python played a
major role in testing Amoeba."
Also, Amoeba was a joint project of the Free University and CWI, both
in Amsterdam.  The project originated at the Free University, and
since CWI stopped the project a while ago, it is once again a project
of the Free University alone.

> Python
> ------
> Through the use of the STDWIN paradigm, the same source code
> can do graphics in the following systems:
>
>   1. X-windows
>   2. Macintosh
>   3. Atari ST
>   4. DOS
>   5. Silicon Graphics SGI workstations
>
> This approach allows flexibility but means that no one graphics system's
> potential is maximized.

On the Silicon Graphics, there is also an interface availible to GL,
the grpahics library, and to FORMS, a graphical user interface toolkit
for Silicon Graphics workstations by Mark H. Overmars.

Sjoerd Mullender
CWI, dept. CST, Kruislaan 413, 1098 SJ Amsterdam, Netherlands
email: [e-mail]        fax:   [phone]
phone: [phone]            telex: 12571 mactr nl










Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP
    id AA25566 (5.65b/2.10/CWI-Amsterdam); Mon, 6 Jul 1992 16:15:02 +0200
Received: by schelvis.cwi.nl with SMTP; Mon, 6 Jul 1992 14:14:58 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Python and audio
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone](home)
X-Last-Band-Seen: Kevin Coyne (Vondelpark, 28-6)
X-Mini-Review: Good! He does not look too healthy in the sun, though...
Date: Mon, 06 Jul 1992 16:14:57 +0200
From: Jack Jansen <[e-mail]>

Is anyone else interested in using python for audio programming? I've
written a couple of extension modules to handle the sun audio device
(the SGI audio library was already supported) and to do all sorts of
operations on audio like conversion from/to U-LAW, ADPCM, etc. that
I'd be willing to share...
--
Jack Jansen        | If I can't dance I don't want to be part of
[e-mail] | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Replied: Tue, 07 Jul 1992 10:11:06 +0200
Replied: "[e-mail] (Lou Kates) "
Received: from uunet.ca by charon.cwi.nl with SMTP
    id AA08661 (5.65b/2.10/CWI-Amsterdam); Tue, 7 Jul 1992 00:20:17 +0200
Received: from tslwat by mail.uunet.ca with UUCP id <10200>; Mon, 6 Jul 1992 18:20:01 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Mon, 6 Jul 92 18:12 EDT
Message-Id: <[e-mail]>
Date:     Mon, 6 Jul 1992 18:12:00 -0400
From: [e-mail] (Lou Kates)
To: [e-mail]
Subject: quickie filters


In perl there are flags to:

     a.   read the program from the command line

     b.   iterate over all the arguments using them as successive
      input files

     c.   automatically split each input line

This makes it easy to write quickie filters.

Perhaps this might be made available for python too? For example,
suppose that -a is autosplit mode and -e reads the python program
from the  next argument.  Then one  might do the following to get
the second  field  from each line  and its  square assuming  that
Python puts   the line into L  and  then splits it into a list of
fields F:

    python -ae 'print F[1], F[1]*F[1]'

if you want to read the input from standard input, or

    python -ae 'print F[1], F[1]*F[1]' infile.dat

if you want to name the file explicity.

---
Lou Kates, [e-mail]










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA23939 (5.65b/2.10/CWI-Amsterdam); Tue, 7 Jul 1992 10:11:44 +0200
Received: by voorn.cwi.nl with SMTP; Tue, 7 Jul 1992 08:11:49 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: quickie filters
In-Reply-To: Your message of "Mon, 06 Jul 1992 18:12:00 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 07 Jul 1992 10:11:48 +0200
Sender: [e-mail]

>In perl there are flags to:
>
>     a.   read the program from the command line

Python has this too -- it's called '-c commands' in analogy with *sh.

>     b.   iterate over all the arguments using them as successive
>      input files
>
>     c.   automatically split each input line
>
>This makes it easy to write quickie filters.
[examples omitted]

Remember that this works with Perl because many other features of the
language are designed to cooperate, e.g. the defaults for regexp
matching etc.  Frankly, I'd rather not try to compete with Perl in the
areas where Perl is best -- it's a battle that's impossible to win,
and I don't think it is a good idea to strive for the number of
obscure options and shortcuts that Perl has acquired through the year.
If you want Perl, use it -- Python wins where you need sophisticated
data structures or object-orientation.

On the other hand, it isn't hard to write a Python script that
emulates these options.  Here's a simple one that emulates -ae:

------------------------------------------------------------------------
#! /usr/local/python

# Wrapper around Python to emulate the Perl -ae options:
# (1) first argument is a Python command
# (2) rest of arguments are input files (default or '-': read stdin)
# (3) each line is put into the string L with trailing '\n' stripped
# (4) the fields of the line are put in the list F
# (5) also: FILE: full filename; LINE: full line; FP: open file object

import sys
import string

command = sys.argv[1]

if not sys.argv[2:]:
    sys.argv[2:] = ['-']

for FILE in sys.argv[2:]:
    if FILE == '-':
        FP = sys.stdin
    else:
        FP = open(FILE, 'r')
    while 1:
        LINE = FP.readline()
        if not LINE: break
        L = LINE[:-1]
        F = string.split(L)
        exec(command)
------------------------------------------------------------------------

This version is inefficient because it parses and "compiles" the
command for each input line, but it is possible to solve that by
creative use of exec().  You can also imagine more useful handling of
missing input files, syntax errors in the script, etc.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Well I'm a plumber.  I can't act"










Received: from uu.psi.com by charon.cwi.nl with SMTP
    id AA05049 (5.65b/2.10/CWI-Amsterdam); Tue, 7 Jul 1992 18:55:06 +0200
Received: from midas.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
    id AA20632; Tue, 7 Jul 92 12:38:10 -0400
Received: from lynchpin.mtkgc.com by mtkgc.COM (4.1/SMI-4.1)
    id AA03203; Tue, 7 Jul 92 08:53:46 EDT
Received: by lynchpin.mtkgc.com (4.1/SMI-4.1)
    id AA13532; Tue, 7 Jul 92 08:55:11 EDT
Date: Tue, 7 Jul 92 08:55:11 EDT
From: [e-mail] (Kevin Samborn)
Message-Id: <[e-mail]>
To: Guido van Rossum <[e-mail]>
Subject: Re: what is the 256 on my screen ?
References: <[e-mail]>
    <[e-mail]>

/\/\ On Thu, 02 Jul 1992 22:48:56 +0200, Guido van Rossum said:

   Terrence> i am starting up a faq for python by the way

   Guido> That's great.  Will it be ftp'able?  I might point new
   Guido> readers of the list to it, to get them up at full speed
   Guido> quickly...

Guido- you might consider posting it periodically to news.answers.
This will make the list easily available (and automatically archived),
and expose lots and lots of people to Python...


kevin

--
kevin samborn
[e-mail]











Replied: Wed, 08 Jul 1992 10:53:48 +0200
Replied: "[e-mail] "
Received: from uunet.ca by charon.cwi.nl with SMTP
    id AA19800 (5.65b/2.10/CWI-Amsterdam); Wed, 8 Jul 1992 02:14:11 +0200
Received: from tslwat by mail.uunet.ca with UUCP id <10219>; Tue, 7 Jul 1992 20:14:05 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Tue, 7 Jul 92 19:19 EDT
Message-Id: <[e-mail]>
From: [e-mail] (Lou Kates)
Subject: Re: quickie filters
To: [e-mail]
Date:     Tue, 7 Jul 1992 19:18:59 -0400
X-Mailer: ELM [version 2.3 PL11]

>
> >In perl there are flags to:
> >     a.   read the program from the command line
> >     b.   iterate over all the arguments using them as successive
> >         input files
> >     c.   automatically split each input line
> >
> >This makes it easy to write quickie filters.
>
...
> On the other hand, it isn't hard to write a Python script that
> emulates these options.  Here's a simple one that emulates -ae:
[example omitted]

This example  seems sufficiently useful,  in general, that it (or
possibly a sligthly enhanced  version of  it) should be added  to
the standard  distributed  Python library. It is  useful not only
for itself but also as a learning example of how you do this sort
of thing in Python.

Lou Kates, [e-mail]










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA27699 (5.65b/2.10/CWI-Amsterdam); Wed, 8 Jul 1992 10:53:48 +0200
Received: by voorn.cwi.nl with SMTP; Wed, 8 Jul 1992 08:53:51 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: quickie filters
In-Reply-To: Your message of "Tue, 07 Jul 1992 19:18:59 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Wed, 08 Jul 1992 10:53:50 +0200
Sender: [e-mail]

Lou Kates writes:
>This example  seems sufficiently useful,  in general, that it (or
>possibly a sligthly enhanced  version of  it) should be added  to
>the standard  distributed  Python library. It is  useful not only
>for itself but also as a learning example of how you do this sort
>of thing in Python.

We are in almost complete agreement!  Here's a (much enhanced) version
that supports more Perl options and parses the script only once.  I
added the -F option in analogy to awk; how do you set the field
separator in Perl?

I've called it "pp.py" and (some version of) it will appear under this
name as a demo script in the next release (whenever that is).  Adding
it to the library won't do much good since the Python library consists
of modules that you can import from other Python programs, while this
is a "script" that normally runs as a main program.

Nasty bug warning: calling it with the option string "-na" will cause
weird behavior if your Python interpreter has stdwin compiled in :-(.
This is because the X11 option processing will eat the "-na" (which it
thinks is an abbreviation for "-name") and the following argument.
Using "-n -a" will work fine.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Now, let's get one thing *quite* clear.  I most definitely told you!"

----------------------------- pp.py ------------------------------------
#! /usr/local/python

# Emulate some Perl command line options.
# Usage: pp [-a] [-c] [-e scriptline] [-F fieldsep] [-n] [-p] [file] ...
# Where the options mean the following:
#   -a            : together with -n or -p, splits each line into list F
#   -c            : check syntax only, do not execute any code
#   -e scriptline : gives one line of the Python script; may be repeated
#   -F fieldsep   : sets the field separator for the -a option [not in Perl]
#   -n            : runs the script for each line of input
#   -p            : prints the line after the script has run
# When no script lines have been passed, the first file argument
# contains the script.  With -n or -p, the remaining arguments are
# read as input to the script, line by line.  If a file is '-'
# or missing, standard input is read.

import sys
import string
import getopt

FS = ''
SCRIPT = []
AFLAG = 0
CFLAG = 0
NFLAG = 0
PFLAG = 0

try:
    optlist, ARGS = getopt.getopt(sys.argv[1:], 'ace:F:np')
except getopt.error, msg:
    sys.stderr.write(sys.argv[0] + ': ' + msg + '\n')
    sys.exit(2)

for option, optarg in optlist:
    if option == '-a':
        AFLAG = 1
    elif option == '-c':
        CFLAG = 1
    elif option == '-e':
        for line in string.splitfields(optarg, '\n'):
            SCRIPT.append(line)
    elif option == '-F':
        FS = optarg
    elif option == '-n':
        NFLAG = 1
        PFLAG = 0
    elif option == '-p':
        NFLAG = 1
        PFLAG = 1
    else:
        print option, 'not recognized???'

if not ARGS: ARGS.append('-')

if not SCRIPT:
    if ARGS[0] == '-':
        fp = sys.stdin
    else:
        fp = open(ARGS[0], 'r')
    while 1:
        line = fp.readline()
        if not line: break
        SCRIPT.append(line[:-1])
    del fp
    del ARGS[0]
    if not ARGS: ARGS.append('-')

if CFLAG:
    prologue = ['if 0:']
    epilogue = []
elif NFLAG:
    # Note that it is on purpose that AFLAG and PFLAG are
    # tested dynamically each time through the loop
    prologue = [ \
        'LINECOUNT = 0', \
        'for FILE in ARGS:', \
        '   \tif FILE == \'-\':', \
        '   \t   \tFP = sys.stdin', \
        '   \telse:', \
        '   \t   \tFP = open(FILE, \'r\')', \
        '   \tLINENO = 0', \
        '   \twhile 1:', \
        '   \t   \tLINE = FP.readline()', \
        '   \t   \tif not LINE: break', \
        '   \t   \tLINENO = LINENO + 1', \
        '   \t   \tLINECOUNT = LINECOUNT + 1', \
        '   \t   \tL = LINE[:-1]', \
        '   \t   \taflag = AFLAG', \
        '   \t   \tif aflag:', \
        '   \t   \t   \tif FS: F = string.splitfields(L, FS)', \
        '   \t   \t   \telse: F = string.split(L)' \
        ]
    epilogue = [ \
        '   \t   \tif not PFLAG: continue', \
        '   \t   \tif aflag:', \
        '   \t   \t   \tif FS: print string.joinfields(F, FS)', \
        '   \t   \t   \telse: print string.join(F)', \
        '   \t   \telse: print L', \
        ]
else:
    prologue = ['if 1:']
    epilogue = []

# Note that we indent using tabs only, so that any indentation style
# used in 'command' will come out right after re-indentation.

program = string.joinfields(prologue, '\n') + '\n'
for line in SCRIPT:
    program = program + ('   \t   \t' + line + '\n')
program = program + (string.joinfields(epilogue, '\n') + '\n')

import tempfile
tfn = tempfile.mktemp()
try:
    fp = open(tfn, 'w')
    fp.write(program)
    fp.close()
    execfile(tfn)
finally:
    import os
    try:
        os.unlink(tfn)
    except:
        pass










Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP
    id AA28341 (5.65b/2.10/CWI-Amsterdam); Wed, 8 Jul 1992 11:36:41 +0200
Received: by schelvis.cwi.nl with SMTP; Wed, 8 Jul 1992 09:36:40 GMT
Message-Id: <[e-mail]>
To: Guido van Rossum <[e-mail]>
Cc: [e-mail]
Subject: Re: quickie filters
In-Reply-To: Message by Guido van Rossum <[e-mail]> ,
         Wed, 08 Jul 1992 10:53:50 +0200 , <[e-mail]>
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone](home)
X-Last-Band-Seen: Scene (Vondelpark, 5-7)
X-Mini-Review: Too crowded.
Date: Wed, 08 Jul 1992 11:36:39 +0200
From: Jack Jansen <[e-mail]>

Python is a truly wonderful language. When somebody comes up with a
good idea it takes about 1 minute and five lines to program something
that almost does what you want. Then it takes only an hour to extend
the script to 300 lines, after which it still does almost what you
want:-)
--
Jack Jansen        | If I can't dance I don't want to be part of
[e-mail] | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Received: from uunet.ca by charon.cwi.nl with SMTP
    id AA03106 (5.65b/2.10/CWI-Amsterdam); Wed, 8 Jul 1992 16:05:17 +0200
Received: from tslwat by mail.uunet.ca with UUCP id <9720>; Wed, 8 Jul 1992 10:04:54 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Wed, 8 Jul 92 08:51 EDT
Message-Id: <[e-mail]>
From: [e-mail] (Lou Kates)
Subject: Re: quickie filters
To: [e-mail]
Date:     Wed, 8 Jul 1992 08:51:34 -0400
X-Mailer: ELM [version 2.3 PL11]


>
> We are in almost complete agreement!  Here's a (much enhanced) version
> that supports more Perl options and parses the script only once.  I

Thanks!

> added the -F option in analogy to awk; how do you set the field
> separator in Perl?

I don't think there is any way  to specify the field separator to
autosplit mode in  Perl like  you can in awk. If you do the split
yourself rather than use autosplit mode  then you can specify the
pattern on which to split as an argument to the split function. I
am not  a Perl expert but this is  my understanding from  reading
the manual I have.

Lou Kates, [e-mail]










Replied: Thu, 09 Jul 1992 10:06:11 +0200
Replied: "Python Mailing List <[e-mail]> "
Received: from [138.95.19.12] by charon.cwi.nl with SMTP
    id AA18809 (5.65b/2.10/CWI-Amsterdam); Thu, 9 Jul 1992 01:30:49 +0200
Received: from eng2.sequent.com by gateway.sequent.com (5.61/1.34)
    id AA08017; Wed, 8 Jul 92 16:28:34 -0700
Received: by eng2.sequent.com (5.65/1.34)
    id AA03564; Wed, 8 Jul 92 16:30:35 -0700
Message-Id: <[e-mail]>
To: Python Mailing List <[e-mail]>
Subject: python and stdwin: question and observation
Priority: Normal
Precedence: first-class
Organization: Sequent Computer Systems, Inc.
          Decision Support Group - MailStop: RHE2-358
          15450 S.W. Koll Parkway
          Beaverton, OR  97006
X-Phone: [phone]
X-Fax: [phone]
X-Uucp: ...!uunet!sequent!jaap
X-Internet: [e-mail]
X-Face: C4Cnai$>Eja5I6Vq?(gdN#SXX#`-XgAnmUn&e54sx7@1>q@vkrd_XnH![P>w.:7IJJ;{Bts
 WJd)u&G!V}0OR?2o5cUgIY}.T{g]PMC=*~]3n_t)S-ZkC(WG}3:#hcA6Oazx:}yc&k,hsF7D},7x>l
 nyfRjO7$@]fHBN>aC9-M3pKfbYHiy!PWD{_bx~fo})b4tU.;Ao%x[upCI,
Date: Wed, 08 Jul 92 16:30:34 PDT
From: Jaap Vermeulen <[e-mail]>


I was looking around for a listbox inside a window.  I can't find any
example such a thing (maybe I'm just overlooking it?).  Mainly I want
to position two listboxes (or scrollboxes or whatever you wanna call
'm) within a single window.

While I was looking around to find a listbox, I looked at the DirList
code and ran the TestDirList.py stdwin demo.  Now this demo is
*painfully* slow and uses gobs and gobs of processor time.  Is this
normal?

% time Python TestDirList.py

Time: 2:28.41 total  137.090 user  4.080 system  95.1% CPU
IO:   59+1 io  391+3 r/w syscalls  0+0 raw r/w
Mem:  0+14058 maj/min pf  137+344 incr/decr pff  0 max 187 zero 0 swaps
Sys:  147+1 vol/invol ctxsw  2306 system calls  0 signals

This means that in a little over two minutes I burned a little over two
minutes of CPU time (gulp!).  And the only thing I did is open five
directories or so (I started somewhere in ~/lib/python/demos/stdwin and
went up to the parent directory five times until I was in my home
directory).  And the code is not spinning, since it wouldn't burn
anything if I didn't touch it.  Insights anyone (read:  Guido :-).

Thanks,

    -Jaap-
--
Jaap Vermeulen                    +--------------------------+
                        | Sequent Computer Systems |
    Internet : [e-mail]        | Beaverton, Oregon       |
    Uucp     : ...uunet!sequent!jaap    +--------------------------+










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA04556 (5.65b/2.10/CWI-Amsterdam); Thu, 9 Jul 1992 10:06:13 +0200
Received: by voorn.cwi.nl with SMTP; Thu, 9 Jul 1992 08:06:15 GMT
Message-Id: <[e-mail]>
To: Python Mailing List <[e-mail]>
Subject: Re: python and stdwin: question and observation
In-Reply-To: Your message of "Wed, 08 Jul 1992 16:30:34 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 09 Jul 1992 10:06:14 +0200
Sender: [e-mail]

Jaap Vermeulen <[e-mail]> writes:

>I was looking around for a listbox inside a window.  I can't find any
>example such a thing (maybe I'm just overlooking it?).  Mainly I want
>to position two listboxes (or scrollboxes or whatever you wanna call
>'m) within a single window.

There isn't any, but DirList is indeed a good example for how to build
one out of buttons and splits.  Note, however, that all these
widget-type things were part of a project that I never finished (hence
the abhorring lack of documentation :-).  One of the reasons was
indeed that it felt too slow to be useful in practice.  Another reason
was that I never could invent a really simple programmer interface,
either with or without multiple inheritance.  Maybe this widget stuff
isn't easy as I thought?  The serious window systems [Andrew, X11,
Windows3.1] are all too big, and the small ones [e.g. Rob Pike's one
for Plan 9] suffer from lack of flexibility...

>% time Python TestDirList.py
>
>Time: 2:28.41 total  137.090 user  4.080 system  95.1% CPU
>IO:   59+1 io  391+3 r/w syscalls  0+0 raw r/w
>Mem:  0+14058 maj/min pf  137+344 incr/decr pff  0 max 187 zero 0 swaps
>Sys:  147+1 vol/invol ctxsw  2306 system calls  0 signals

I also played around with it a little and found this, opening 7 or 8
directories in a minute:

|& time python TestDirList.py
|
|real     1:10.1
|user        3.6
|sys         0.8
|&

Now this is on a 33 MHz SGI Indigo, a real racing car.  Is your
machine slow or memory-starved?  (14058 minor page faults looks like a
lot to me).

On the other hand it could be that your realloc() implementation is
slow.  If this is the case, building lists by appending elements to
the end one by one (as is done by os.listdir(), for example) may
become an O(n**2) matter since realloc() is copying the entire array
on each expansion.  Most current malloc packages are cleverer than
that, so I didn't bother to try and optimize this in the Python code,
but if you're adventurous you could dive into the "listobject" source
code and somehow extend the array used to hold the list in larger
chunks.

Of course, I'd try to profile python first, just to get more insight
(and yes, even on my system malloc is on top of the list).

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Anyone capable to get themselves elected president should on no
account be allowed to do the job."










Replied: Thu, 09 Jul 1992 23:53:52 +0200
Replied: Python Mailing List <[e-mail]>
Received: from [138.95.19.12] by charon.cwi.nl with SMTP
    id AA16482 (5.65b/2.10/CWI-Amsterdam); Thu, 9 Jul 1992 19:50:45 +0200
Received: from eng2.sequent.com by gateway.sequent.com (5.61/1.34)
    id AA04224; Thu, 9 Jul 92 10:48:34 -0700
Received: by eng2.sequent.com (5.65/1.34)
    id AA09779; Thu, 9 Jul 92 10:50:37 -0700
Message-Id: <[e-mail]>
To: Guido van Rossum <[e-mail]>
Cc: Python Mailing List <[e-mail]>
Subject: Re: python and stdwin: question and observation
Priority: Normal
Precedence: first-class
Organization: Sequent Computer Systems, Inc.
              Decision Support Group - MailStop: RHE2-358
          15450 S.W. Koll Parkway
              Beaverton, OR  97006
X-Phone: [phone]
X-Fax: [phone]
X-Uucp: ...!uunet!sequent!jaap
X-Internet: [e-mail]
X-Face: C4Cnai$>Eja5I6Vq?(gdN#SXX#`-XgAnmUn&e54sx7@1>q@vkrd_XnH![P>w.:7IJJ;{Bts
 WJd)u&G!V}0OR?2o5cUgIY}.T{g]PMC=*~]3n_t)S-ZkC(WG}3:#hcA6Oazx:}yc&k,hsF7D},7x>l
 nyfRjO7$@]fHBN>aC9-M3pKfbYHiy!PWD{_bx~fo})b4tU.;Ao%x[upCI,
In-Reply-To: Guido van Rossum's message of Thu, 09 Jul 92 10:06:14 +0200.
             <[e-mail]>
Date: Thu, 09 Jul 92 10:50:36 PDT
From: Jaap Vermeulen <[e-mail]>


| There isn't any, but DirList is indeed a good example for how to build
| one out of buttons and splits.  Note, however, that all these

The problem, though, is that I don't know how to put multiple DirLists
in a single window. Or is it plain impossible? (In that case: bye,
bye, stdwin. :-)

| either with or without multiple inheritance.  Maybe this widget stuff
| isn't easy as I thought?  The serious window systems [Andrew, X11,
| Windows3.1] are all too big, and the small ones [e.g. Rob Pike's one
| for Plan 9] suffer from lack of flexibility...

What I'm missing is a high level abstraction model for "accepted" user
interface objects, such as dialog boxes with elements such as a listbox.

| I also played around with it a little and found this, opening 7 or 8
| directories in a minute:
|
| |& time python TestDirList.py
| |
| |real     1:10.1
| |user        3.6
| |sys         0.8
| |&
|
| Now this is on a 33 MHz SGI Indigo, a real racing car.  Is your
| machine slow or memory-starved?  (14058 minor page faults looks like a
| lot to me).

I'm running on a 12 processor, 300Mb symmetry, and the load average is
below .5 with ~60 people. It's not the fastest machine, but certainly
nearly 100% processor utilization time (which means I used one of the
twelve processors almost exclusively; and note: the utilization time
can go as high as 1200%) is very suspicious...

| On the other hand it could be that your realloc() implementation is
| slow.  If this is the case, building lists by appending elements to

Now *that* is an interesting assumption. I compiled in the optional
malloc library which implements the bucket algorithm. And lo and behold,
it is much better, but not close to what you show. It lookes like the
size of the directory is also pretty important... Maybe there are malloc
packages that are *really* smart? Here are some memory statistics:

Process: python  pid: 8853  text_handle: 0x01b8f364  KB pte: 12
                      Values in K Bytes
Segment       Virtual  Resident  Weighted RSS <- this is the only process
text            408        208      208.00     running, so there is nothing
data+bss       1236        880      880.00     to weigh (otherwise text
stack            12         12       12.00     would be shared)
shared            0          0        0.00

Total          1656       1100     1100.00

FYI: the paging algorithms on this system are set up to let processes
     go up to 3Mb before *really* pruning them.

| the end one by one (as is done by os.listdir(), for example) may
| become an O(n**2) matter since realloc() is copying the entire array
| on each expansion.  Most current malloc packages are cleverer than
| that, so I didn't bother to try and optimize this in the Python code,
| but if you're adventurous you could dive into the "listobject" source
| code and somehow extend the array used to hold the list in larger
| chunks.

No time for adventures right now. :-)

| Of course, I'd try to profile python first, just to get more insight
| (and yes, even on my system malloc is on top of the list).

OK, here is what I got (only the highest entries on the list):

 %Time Seconds Cumsecs  #Calls   msec/call  Name
  21.6   16.58   16.58   23698      0.6997  newdictobject
  15.6   11.97   28.56   23182      0.5165  eval_code
  10.5    8.03   36.58  262848      0.0305  malloc
  10.4    7.97   44.55                      _mcount
   4.8    3.70   48.25  262277      0.0141  free
   3.4    2.58   50.83  582599      0.0044  strcmp
   3.3    2.52   53.35   34252      0.0736  call_object
   2.4    1.86   55.22     503      3.71    stat
   1.8    1.36   56.58   94046      0.0145  settupleitem
   1.8    1.35   57.93  183854      0.0074  dict2lookup
   1.7    1.34   59.27  107153      0.0125  dict2insert
   1.6    1.21   60.48      30     40.3     newclassobject
   1.2    0.93   61.41  181919      0.0051  gettupleitem
   1.1    0.84   62.25     877      0.96    getdictkey
   1.0    0.75   63.00  158436      0.0047  gettuplesize
   1.0    0.75   63.75   98732      0.0076  cmpobject
   1.0    0.73   64.48    1182      0.618   putmsg

malloc is *not* on the top of the list. :-) Is this normal?  Any other
input as to why it may be so cpu intensive?

Thanks,

    -Jaap-
--
Jaap Vermeulen                    +--------------------------+
                        | Sequent Computer Systems |
    Internet : [e-mail]        | Beaverton, Oregon       |
    Uucp     : ...uunet!sequent!jaap    +--------------------------+










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA21647 (5.65b/2.10/CWI-Amsterdam); Thu, 9 Jul 1992 23:53:46 +0200
Received: by voorn.cwi.nl with SMTP; Thu, 9 Jul 1992 21:53:51 GMT
Message-Id: <[e-mail]>
To: Python Mailing List <[e-mail]>
Subject: Re: python and stdwin: question and observation
In-Reply-To: Your message of "Thu, 09 Jul 1992 10:50:36 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 09 Jul 1992 23:53:50 +0200
Sender: [e-mail]

Jaap Vermeulen <[e-mail]> writes:

>The problem, though, is that I don't know how to put multiple DirLists
>in a single window. Or is it plain impossible? (In that case: bye,
>bye, stdwin. :-)

Check out the HVSplit module, this lets you build an arbitrary widget
tree.

>What I'm missing is a high level abstraction model for "accepted" user
>interface objects, such as dialog boxes with elements such as a listbox.

There are remarkably many of these and it is remarkably hard to make
them general enough -- again, see the size of Motif and Windows.

>Now *that* is an interesting assumption. I compiled in the optional
>malloc library which implements the bucket algorithm. And lo and behold,
>it is much better, but not close to what you show. It lookes like the
>size of the directory is also pretty important...

Of course it is, if the algorithm is O(n**2)...  Unfirtunately I have
little idea of what to do about this particular problem.  Anybody
know about a really fast malloc library?  I seem to remember that the
best ones keep separate free lists per size, rounded to powers of two.

> %Time Seconds Cumsecs  #Calls   msec/call  Name
>  21.6   16.58   16.58   23698      0.6997  newdictobject
>  15.6   11.97   28.56   23182      0.5165  eval_code
>  10.5    8.03   36.58  262848      0.0305  malloc
>  10.4    7.97   44.55                      _mcount
>   4.8    3.70   48.25  262277      0.0141  free
>   3.4    2.58   50.83  582599      0.0044  strcmp
>   3.3    2.52   53.35   34252      0.0736  call_object

Hmm, the newdictobject on top is suspicious, it doesn't do anything
that could take 0.7 msec.  I suspect its time may include the time
taken by lookdict(), the next function in the file which happens to be
static and is used for every local variable reference (most calls to
strcmp() come from there I would guess).  Don't you have a more modern
profiler, e.g. gprof?  The number of eval_code calls (the main
interpreter loop) reflects mostly the number of function calls, and
most newdictobject() calls are for the dictionaries of local variables.
(I suppose there's an opportunity for a code optimizer here. :-)

That's my two cents worth for now...

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Did you say knives?"
"Rotating knives, yes"










Replied: Sun, 12 Jul 1992 12:53:56 +0200
Replied: [e-mail]
Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA22292 (5.65b/2.10/CWI-Amsterdam); Sun, 12 Jul 1992 01:58:02 +0200
Received: from stun4q.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA26328; Sat, 11 Jul 92 16:56:50 PDT
Date: Sat, 11 Jul 92 16:56:50 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4q.cs.caltech.edu (4.1/SMI-4.1)
    id AA14315; Sat, 11 Jul 92 16:58:03 PDT
To: [e-mail]
Subject: Is delayed evaluation possible ?
Comments: Hyperbole mail buttons accepted, v3.02P.

I am doing a large amount of substitution of variables into LONG strings in
python. The length of these strings is making my code unreadable.

2 questions:
Is it possible to alias a string that will have variables substituted
into it if the variables are not already defined such as:

xdr_stream.append('xdr_' dataType + \
    '(&(M_RemoteProcessPointer->xdr_write), \
    + rpc_arg + '); \n)

can i do substr = ('xdr_' dataType + \
    '(&(M_RemoteProcessPointer->xdr_write), \
    + rpc_arg + '); \n)

xdr.stream.append(substr) so that I dont have to ugly up my code ?

This also has another question built into it as to whether or not
unbound variables in strings are possible through the use of delayed
evaluation. This is a nice feature that Tcl has.



--
terrence brannon
[e-mail]











Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA27355 (5.65b/2.10/CWI-Amsterdam); Sun, 12 Jul 1992 12:53:52 +0200
Received: by voorn.cwi.nl with SMTP; Sun, 12 Jul 1992 10:53:55 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Is delayed evaluation possible ?
In-Reply-To: Your message of "Sat, 11 Jul 1992 16:56:50 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Sun, 12 Jul 1992 12:53:54 +0200
Sender: [e-mail]

[e-mail] (Terrence M. Brannon) writes:

>Is it possible to alias a string that will have variables substituted
>into it if the variables are not already defined such as:
>
>xdr_stream.append('xdr_' dataType + \
>    '(&(M_RemoteProcessPointer->xdr_write), \
>    + rpc_arg + '); \n)
>
>can i do substr = ('xdr_' dataType + \
>    '(&(M_RemoteProcessPointer->xdr_write), \
>    + rpc_arg + '); \n)
>
>xdr.stream.append(substr) so that I dont have to ugly up my code ?
>
>This also has another question built into it as to whether or not
>unbound variables in strings are possible through the use of delayed
>evaluation. This is a nice feature that Tcl has.

No, there is no delayed evaluation of strings in Python, but you can
do what you want using a function (which is of course the more general
way of expressing delayed evaluation of anything):

def substr(dataType, rpc_arg):
    return 'xdr_' + dataType + \
       '(&(M_RemoteProcessPointer->xdr_write), ' \
       + rpc_arg + '); \n'

(note that I have supplied some missing quotes and operators in your
example :-) and then write

xdr.stream.append(substr(dataType, rpc_arg)).

You may be able to shorten your code even more if you change the
function arguments into global variables -- personally I don't like
the use of globals when arguments could be used, and Python reflects
this view by forcing you to declare your globals as such in every
function that assigns to them.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Exploding is a perfectly normal medical phenomenon."











Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA28738 (5.65b/2.10/CWI-Amsterdam); Sun, 12 Jul 1992 18:08:20 +0200
Received: from stun4q.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA26704; Sun, 12 Jul 92 09:07:04 PDT
Date: Sun, 12 Jul 92 09:07:03 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4q.cs.caltech.edu (4.1/SMI-4.1)
    id AA14370; Sun, 12 Jul 92 09:08:21 PDT
To: [e-mail]
Subject: A question on the direction of Python
Comments: Hyperbole mail buttons accepted, v3.02P.

I notice I have to do certain things by myself in Python that it would
be nice if there were registers for. The one example I keep running
into right now is if I have a loop like this:

tmp = open('file','r').readlines()
iterationCount=0
for line in tmp:
    iterationCount = iterationCount + 1
    if regex.match('adfasdf',line) > 5
        break
    else:
        serverloop_code.insert(iterationCount,line)  # line X

It would be nice if iterationCount were a pre-defined register like @i
or something so the code could be more compact . However, it would be
more cryptic to someone just getting into the language. Registers were
the main thing that made me quit learning Perl quickly.

Another way to look at this is that since Python is an object-oriented
language the for statement above is sending a message to `for' with 2
arguments. Since objects have their own private data, it would seem
that we could type serverloop_code.insert(for.current_pos(), line) at
line X to access some data in the `for' object.

What do you all think ?

--
terrence brannon
[e-mail]











Received: from uunet.ca by charon.cwi.nl with SMTP
    id AA29511 (5.65b/2.10/CWI-Amsterdam); Sun, 12 Jul 1992 20:07:34 +0200
Received: from tslwat by mail.uunet.ca with UUCP id <9677>; Sun, 12 Jul 1992 14:07:32 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Sun, 12 Jul 92 14:10 EDT
Message-Id: <[e-mail]>
From: [e-mail] (Lou Kates)
Subject: Re: iteration count register
To: [e-mail]
Date:     Sun, 12 Jul 1992 14:10:41 -0400
X-Mailer: ELM [version 2.3 PL11]

Forwarded message:
> From:    [e-mail] (Terrence M. Brannon)
>
> I notice I have to do certain things by myself in Python that it would
> be nice if there were registers for. The one example I keep running
> into right now is if I have a loop like this:
>
> tmp = open('file','r').readlines()
> iterationCount=0
> for line in tmp:
>     iterationCount = iterationCount + 1
>     if regex.match('adfasdf',line) > 5
>         break
>     else:
>         serverloop_code.insert(iterationCount,line)  # line X
>
> It would be nice if iterationCount were a pre-defined register like @i
> or something so the code could be more compact . However, it would be
> more cryptic to someone just getting into the language. Registers were
> the main thing that made me quit learning Perl quickly.
>
> Another way to look at this is that since Python is an object-oriented
> language the for statement above is sending a message to `for' with 2
> arguments. Since objects have their own private data, it would seem
> that we could type serverloop_code.insert(for.current_pos(), line) at
> line X to access some data in the `for' object.
>
> What do you all think ?
>
> --
> terrence brannon
> [e-mail]
>
>

> tmp = open('file','r').readlines()
> iterationCount=0
> for line in tmp:
>     iterationCount = iterationCount + 1
>     if regex.match('adfasdf',line) > 5
>         break
>     else:
>         serverloop_code.insert(iterationCount,line)  # line X

Your OO solution seems neat.

Note that  if your only objective  is reduction in code size then
the above  example  could  be reduced   to the  same size as  the
perlized  python  solution by  iterating over an index instead of
over the lines themselves:

    lines = open('file','r').readlines()
    for i in range(len(lines)):
        if regex.match('adfasdf',lines[i]) > 5:
            break
        else:
            serverloop_code.insert(i,lines[i])

My example still has a few problems:

-    you have  to  generate the   range(len(lines)) list. If  the
     number of lines is large this seems rather wasteful.

-    if the  number  of lines   were unbounded then the  previous
     point is  even worse and you have to introduce a number HUGE
     which is unpleasant:

    for i in range(HUGE):

-    there is  an extra array  reference (lines[i]) which adds to
     complexity

On the  other hand  this solution  has one less variable than the
perlized python  solution and the  variable it eliminates is  the
builtin register variable which is the one most onerous.


--
Lou Kates, [e-mail]










Replied: Tue, 14 Jul 1992 10:25:26 +0200
Replied: "[e-mail] "
Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA22963 (5.65b/2.10/CWI-Amsterdam); Tue, 14 Jul 1992 03:08:58 +0200
Received: from stun4b.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA28703; Mon, 13 Jul 92 18:07:31 PDT
Date: Mon, 13 Jul 92 18:07:31 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4b.cs.caltech.edu (4.1/SMI-4.1)
    id AA04784; Mon, 13 Jul 92 18:08:58 PDT
To: [e-mail]
Subject: Inital attempt to make emacs an object
Comments: Hyperbole mail buttons accepted, v3.02P.

The next two posts are my first attempt to create communication
between emacs and python.

Currently a python script which imports the emacs.py module will be
able to issue these three commands:

emacs.dired        ex: emacs.dired('.')  emacs.dired('~')
emacs.buffer_menu   ex: emacs.buffer_menu()
emacs.eval          use any valid elisp form. outermost parenths optional
            ex: emacs.eval('copy-file "/[e-mail]:x" "y" t)
                : emacs.eval('message "hi there"')
                : emacs.eval('(progn (find-file "source.el") (eval-current-buffer))')


The next file is the python script.
The file after that is the emacs lisp.

Follow the directions in the emacs lisp source.

--
terrence brannon
[e-mail]











Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA23155 (5.65b/2.10/CWI-Amsterdam); Tue, 14 Jul 1992 03:23:27 +0200
Received: from stun4b.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA28839; Mon, 13 Jul 92 18:21:44 PDT
Date: Mon, 13 Jul 92 18:21:43 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4b.cs.caltech.edu (4.1/SMI-4.1)
    id AA04786; Mon, 13 Jul 92 18:23:10 PDT
To: [e-mail]
Subject: emacs.py
Comments: Hyperbole mail buttons accepted, v3.02P.

# Initial attempt to make emacs a useable object of python
# This code will be imported from a python interpreter that is running
# as an inferior process of emacs

start_marker = '+'
end_marker   = '~'

def eval (string):
    tmpstr = start_marker + '(' + string + ')' + end_marker
    print tmpstr
print 'method eval(string):'

def dired (directory):
    eval( 'dired ' + '"' + directory + '"' )
print 'method dired(directory):'

def buffer_menu ():
    eval( 'buffer-menu(buffer-list)' )
print 'method buffer_menu():'


print 'module py_emacs loaded.'










Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA23169 (5.65b/2.10/CWI-Amsterdam); Tue, 14 Jul 1992 03:24:23 +0200
Received: from stun4b.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA28842; Mon, 13 Jul 92 18:22:57 PDT
Date: Mon, 13 Jul 92 18:22:57 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4b.cs.caltech.edu (4.1/SMI-4.1)
    id AA04787; Mon, 13 Jul 92 18:24:24 PDT
To: [e-mail]
Subject: py-connect.el
Comments: Hyperbole mail buttons accepted, v3.02P.

(require 'comint)
;;; python-connect.el
;;; Project
;;; Allow the creation of multiple emacs objects which can be queried
;;; and commanded. Primary reason is to use ange-ftp from python since
;;; it is a big headache to re-code all of ange-ftp in python - plus
;;; why re-invent the wheel.
;;;
;;; Technique
;;; Basically we spawn a python interpreter as an inferior process of
;;; emacs and then filter its output . If we get a string delimited
;;; by the start and end markers then we evaluate it.
;;;
;;; Requirements
;;; comint.el and cmushell.el both available from:
;;; "/[e-mail]:pub/gnu/emacs/elisp-archive/packages"
;;; python, available from:
;;; "/[e-mail]:pub"
;;;
;;; Usage
;;; C-x C-f python.connect.el (or whatever you name this)
;;; M-x eval-current-buffer
;;; M-x py-connect
;;; At the python prompt (>>>) type import emacs (if you named the
;;; python script emacs.py -- be sure it is on your load path)
;;; Now at the python prompt you may call any of the defined modules.
;;; ex: emacs.dired('.')
;;; You may also type elisp strings delimited by + and ~ and they will
;;; be evaluated in emacs after you hit return.
;;; ex: +(copy-file "/[e-mail]:yoga" "my-yoga" t)~
;;;
;;; SCOPES FOR IMPROVEMENT
;;; an extremely robust interface would allow one to do completion by
;;; sending an obarray/assoc list and complete-file-name command to
;;; emacs . then get back the results
;;;
;;; Another project
;;; Another possibility is to make it so you can run python without it being
;;; on your local machine - just telnet to the Python interpreter port and
;;; tell it whether you are using x-windows or whatnot.
;;; - games
;;; - demos . see where they are calling from . ange-ftp a file to their
;;;   home directory
;;; - portmapper
;;;
;;; Another project
;;; NOTE: remote emacs-code becomes executable if it shows up in a buffer
;;; because emacs has a built in interpreter . if we have
;;; self-intelligent interpreters, they can show up on your remote
;;; machine and do their work, remember the results, and leave. just
;;; tell the objects what to do and they head over to the correct
;;; machine and do it

(setq start-mkr ?+)
(setq start-mkr-string (char-to-string ?+))
(setq end-mkr-string (char-to-string ?~))

(setq accum-string "")

(defun py-connect ()
  (interactive)
  (cond ((not (comint-check-proc "*py-connect*"))
     (let* ((prog "python")
        (name (file-name-nondirectory prog)))
       (set-buffer (apply 'make-comint "py-connect" (list prog)))
       (comint-mode))))
  (switch-to-buffer "*py-connect*")
  (setq comint-prompt-regexp ">>>")
  (setq P (get-buffer-process (current-buffer)))
  (set-process-filter P 'elisp-filter))

(defun elisp-filter (process string)
  "Make sure that the window continues to show the most recently output
text."

  (let ((old-buffer (current-buffer)))
    (unwind-protect
    (let (moving)
      (set-buffer (process-buffer process))
      (setq moving (= (point) (process-mark process)))
      (save-excursion
        (goto-char (process-mark process))
        (insert string)
        (set-marker (process-mark process) (point)))
      (if moving (goto-char (process-mark process))))
      (set-buffer old-buffer)))

  (while (not (string-equal string ""))
    (let ((s (string-match start-mkr-string string))
      (e (string-match end-mkr-string string)))
      (if (string-equal accum-string "")
      (progn
        (setq expecting 'start-marker)
        (if s
        (progn
          (setq expecting 'end-marker)
          (if e
              (progn
            (interp-elisp (substring string (1+ s) e))
            (setq string (substring string (1+ e))))
            (progn
              (setq accum-string (substring string (1+ s)))
              (setq string ""))))
          (setq string "")))
    (if e
        (progn
          (interp-elisp (concat accum-string (substring string 0 (1- e))))
          (setq string (substring string (1+ e))))
      (setq accum-string (concat accum-string string))
      (setq string ""))))))


(defun interp-elisp (string)
  (eval (read string)))

;;; hacking from here on out -- ignore (or enjoy)


(defun filter-accum-command (string)
  "This function is only called to reset the systems idea of the
currently accumulated output from the process if output is already in
accum-string and possibly evaluate this output if end-mkr is seen.
What it does is check for the first start-mkr and end-mkr in the
string. If neither exists, <return> the concatenation of string onto
accum-string and <exit>. If start-mkr is first, then the accumulated
string is reset to STRING from start-mkr+1 onward and we recursively
call this function. If end-mkr is first, then we evaluate (concat
accum-string STRING up-to-end-mkr), search for the next start-mkr. If
no start-mkr, <return> empty quotes and <exit>. If a start-mkr,
<return> from start-mkr to end of STRING and <exit>"
  (debug)
  (let* ((s (string-match start-mkr-string string))
     (e (string-match   end-mkr-string string)))
    (cond
     ((and (not s) (not e))
      (concat accum-string string))
     ((or (< s e) (and s (not e)))
      (filter-accum-command (substring (1+ s) string)))
     ((or (< e s) (and e (not s)))
      (progn
    (interpret-elisp (concat accum-string (substring 0 (1- e)
                             string)))
    (setq string (substring (1+ e) string))
    (let ((st (string-match start-mkr-string string)))
      (if st
          (substring string (1+ st))
        ""))
    )
      )
     )
    )
  )

(defun interpret-elisp (str)
  (message str)
  (eval (car (read-from-string str))))



(defun old-elisp-filter (proc string)
  (interactive)
  ;;; Cases -
  ;;;
  ;;; (0) if accum-string == "", (0.5) expect a start marker.
  ;;; (1.0) accum-string will equal start-marker to finish-marker or
  ;;; start-marker to end of string. if accum-string went to end of
  ;;; string, exit. (1.5) else eval the region, chop the region from the
  ;;; string, set
  ;;; accum-string to "" and retry (0)
  ;;; (2) if accum-string != "", expect a finish marker. if we get a
  ;;; finish marker, (2.5) concat accum string and string up to finish
  ;;; marker, evaluate then pass the remainder of the stream to (0).
  ;;; (3.0) if we get a start-marker, set accum-string to "" , prepend
  ;;; start-marker to string and goto (0). (3.5) if we get neither, append
  ;;; all of string to accum-string, set accum-string to "", then exit

  (if (string-equal accum-string "")
      (case-0 string)
    (case-2 string)))

(defun case-0 (string)
  (let ((count 0)
    (lth (length string)))
    (while (not (equal (elt string count) start-mkr))
        (setq count (1+ count)))
    (if (equal count lth)
    ()
      (progn
    (setq accum-string (do-1-0))
    (if eos
        ()
      (progn
        (do-1-5)
        (setq accum-string "")
        (case-0 string)))))))

(defun case-2 (string)
  (let ((count 0)
    (lth (length string)))
    (while (not (or (equal (elt string count) start-mkr)
            (equal (elt string count) end-mkr)))
      (setq count (1+ count)))
    (if (equal count lth)
    (do-3-5))
    (if (equal (elt string count) end-mkr)
    (progn
      (setq string (do-2-5 string))
      (setq accum-string "")
      (case-0 string))
      (progn
    (setq accum-string "")
    (setq newstr (concat start-mkr string))
    (case-0 newstr)))))


;(comint-proc-query P "\na = [2 , 3, 4] \n")

(defun t ()
  (interactive)
  (pop-to-buffer "*py-connect*")
  (setq comint-eol-on-send 't)
  (visi-input "a = [ 4 ,5 ,6 ] ")
  (visi-input "a"))

(defun visi-input (string)
  (message string)
  (sit-for 1)
  (goto-char (point-max))
  (let* ((end (point))
     (start (progn
          (beginning-of-line 1)
          (point)))
     (line (buffer-substring start end)))
    (while (not (string-match "[ ]*" line))

      (setq end (point))
      (setq start (progn
            (beginning-of-line 1)
            (point)))
      (setq line (buffer-substring start end)))
    (goto-char (point-max))
    (insert string)
    (comint-send-input)
    (goto-char (point-max))))















Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA24844 (5.65b/2.10/CWI-Amsterdam); Tue, 14 Jul 1992 04:55:46 +0200
Received: from stun4b.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA29160; Mon, 13 Jul 92 19:54:20 PDT
Date: Mon, 13 Jul 92 19:54:20 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4b.cs.caltech.edu (4.1/SMI-4.1)
    id AA04803; Mon, 13 Jul 92 19:55:48 PDT
To: [e-mail]
Subject: Re:  A question on the direction of Python
Comments: Hyperbole mail buttons accepted, v3.02P.

------- Start of forwarded message -------
Re: Iteration counts.

If you need the index, then use an indexed for using range() and len() as
generators:

>>> for i in range( 0, len( tmp )):
...        { do something to tmp[i] }


>
> It would be nice if iterationCount were a pre-defined register like @i
> or something so the code could be more compact . However, it would be
> more cryptic to someone just getting into the language. Registers were
> the main thing that made me quit learning Perl quickly.
>

I would NOT want to PERL-ify Python ( at least in THAT sense )!
I agree that that sort of stuff is part of why Perl is hard to read and learn.

A long time ago, I asked Guido for some remarks on his sense of what role
Python was meant to fill. *IF* the role was to be largely an interactive
command language, THEN brevity has a much higher weight as a virtue.
Perl, IMHO, since it is less interactive than Python, fills that sort of
role more poorly, so I see even less excuse for that sort of abbreviation.
[ We want an interactive language to have aliases and other abbreviations,
  but once we start using an editor to enter larger scripts, then readability
  becomes more virtuous than conciseness. ( IMHO ) ]

>
> Another way to look at this is that since Python is an object-oriented
> language the for statement above is sending a message to `for' with 2
> arguments. Since objects have their own private data, it would seem
> that we could type serverloop_code.insert(for.current_pos(), line) at
> line X to access some data in the `for' object.
>
> What do you all think ?
>

Since Python is not a "pure" object-oriented language, there is no way to
send 'for' a message. But you COULD define an object that keeps count of
the number of times it has been assigned to. It would have two instance
variables: value and count; and a method that updates value and increments
count.

- - Steve

======== "If you have a hammer, find a nail" - George Bush,'91  =========
 Steven D. Majewski        University of Virginia Physiology Dept.
 [e-mail]        Box 449 Health Sciences Center
 Voice: (804)-982-0831/32    1300 Jefferson Park Avenue
 FAX:   [phone]        Charlottesville, VA 22908

------- End of forwarded message -------










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA29148 (5.65b/2.10/CWI-Amsterdam); Tue, 14 Jul 1992 10:25:24 +0200
Received: by voorn.cwi.nl with SMTP; Tue, 14 Jul 1992 08:25:28 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Emacs/Python connection; and the future of Python
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 14 Jul 1992 10:25:27 +0200
Sender: [e-mail]

Thanks to Terence Brannon for his Emacs/Python connection.  I've tried
it a bit and it works, but I haven't got the imagination right now to
find a good use for it -- I'm sure others will.  (To save you some
trouble while hunting down the required package "comint.el": the
pointer to it in the source is wrong: it is in the directory "as-is",
not in "packages".)

Regarding the future direction of Python: in my own use and that of
colleagues I find that Python is used more as a replacement for C
programs than as an improved perl or sh; interactive use tends to be
fairly simple (e.g. testing code I've just written, or as a
calculator).  I couldn't do without interactive Python (nor with the
command line editing) but I wouldn't use it to replace the shell
either.  What do other people use interactive Python for?

I'm leaving today for a vacation until July 30, so don't expect the
quick answers from me to all sorts of questions you're used to...

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Well ass a matter of fact it's *very* runny, sir"










Received: from uvaarpa.Virginia.EDU by charon.cwi.nl with SMTP
    id AA05707 (5.65b/2.10/CWI-Amsterdam); Tue, 14 Jul 1992 16:31:52 +0200
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa28682;
          14 Jul 92 10:24 EDT
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA15115; Tue, 14 Jul 92 10:23:03 EDT
Date: Tue, 14 Jul 92 10:23:03 EDT
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: What do I use python for?  ( A testimonial! )


> To: [e-mail]

> From: Guido van Rossum <[e-mail]>
>
> Regarding the future direction of Python: in my own use and that of
> colleagues I find that Python is used more as a replacement for C
> programs than as an improved perl or sh; interactive use tends to be
> fairly simple (e.g. testing code I've just written, or as a
> calculator).  I couldn't do without interactive Python (nor with the
> command line editing) but I wouldn't use it to replace the shell
> either.  What do other people use interactive Python for?
>

I use python for:

(1) Some of the usual sed/awk/perl type file munging.
    For a while, perhaps, I was overdoing it at trying to use Python as
    a replacement: I was in the middle of a ~10 line Python program when
    I realized I could do the job with an awk one liner. On the other
    hand, I often can't remember of get straight the proper escapes for
    sed, so I used python yesterday to convert all of the carriage-returns
    into line-feeds in a file. After '/015' and '/r' didn't work in sed,
    it was easier to type a couple extra lines in python than dig out
    the manual. If I was more of a wizzard at those other tools, I might
    not use python, but python is easier to learn and remember, and
    sometimes if I can't remember the name of a method, I can cheat and
    type something like "[].__methods__" or "dir(module)" and I don't
    have to dig out the manual.

(2) System management "perl" type jobs. Generating disk usage reports, etc.

(3) Some iteractive shell type stuff where I'm not sure what I'm doing
    when I start. I may want to recursivly build a list of files with
    some defining criteria... and then when I discover that there are
    "too many" , pare that list down by some other criterion , before
    actually doing something with the list.

(4) Before I started to use GnuPlot, I used to use Python to read in
    data files ( spectra ) and do some calculations on them ( difference
    and normalizing ) and pipe them to "|plot |tek &". I had a 'plot'
    routine that did a 'popen' and wrote out a list of numbers to the
    pipe. With GnuPlot, I've just been putting the intermediate data
    into a file. GnuPlot plots functions OR files BUT NOT functions OF
    files, so I miss this. ( You can't say 'plot "data.1" - "data.2" '
    for instance. ) I haven't looked into GnuPlot, so I don't know if
    it would be easy to add, or if I should adapt my python/plot scheme
    to gnuplot.

(5) As Guido said, above: as a replacement for C, or at it's best, where
    I probably wouldn't have written a C program at all, but used a
    calculator or 'bc' and a pencil. Often, what I think is going to
    be a small job ends up getting more complicated.

    Example: We got a new detector for our X-ray spectrometer, and since
    the absorption characteristics was radically different from the
    previous ones, we had to rebuild our least-squares-fit elemental
    references from scratch. ( Something I had never done and no one
    else remembered doing - I used to go to our Physicist and get some
    "magic numbers" to plug in - now all I had was one of his papers. )
    Part of the process involved peak ratio's ( weighted by atom ratio's)
    of "binary" standards : KCl, NaCl, Na2SO4 - something I could have
    done with a calculator, but I had the feeling that it probably wouldn't
    work right the first time, so I might as well write a Python program to
    do it. Well: I didn't work out the first time. There was obviously
    someting wrong with the data going in, and I was glad I wrote a
    python program which I could extend to do some detective work:
    The program calculated the ratio's, added the inverse ratio's to a
    table, and given any one initial absolute value, it calculated the
    values of all of the other elements recursively, sorted them by both
    value and element and printed them along with a "trace". Inconsistencies
    were easier to spot and the trace helped to show which sample was "bad".
    ( If you started with Ca = 1.0, it generate values from all of the
      Ca-to-something ratio's, then all of the something to something else,
     etc. so you would end up with, say, 4 values for Mg, derrived from
     different chains of ratios, and if the were not all nearly equal,
     then some value up the chain was bad. ) The fact that I did not
    have to deal with  any low level list-pointer processing made none
    of this daunting. ( Even though it had become a bigger job than I
    initially thought, it STILL had to be done in a couple days! )


    Sorry if I bore you with details, but I just wanted to illustrate
    how sometimes those "quickies" end up being bigger jobs that you
    expected. ( I'm sure everyone has there own experience of that sort. )
    And I found Python marvelous at that sort of thing. It was simple
    to add the "audit trail" to my calculation after I found out that
    was needed. It didn't kill any other code. It would have been even
    simpler if I had done it in a more object-oriented style. I wasn't
    that adept at Python when I started, so I used lists.


    I'm currently working more on the data-acquisition end of things,
    but if I ever get back to the data-PROCESSING part, an interactive
    graphics & statistical package in python might be a good project.

    I haven't tried the socket library in python yet, but since current
    jobs involve some distributed processing, I will probably use python
    to interactively debug my applications with a prototype ("stub") server.


    Much Thanks for a great tool, Guido!

  - Steve


======== "If you have a hammer, find a nail" - George Bush,'91  =========
 Steven D. Majewski        University of Virginia Physiology Dept.
 [e-mail]        Box 449 Health Sciences Center
 Voice: (804)-982-0831/32    1300 Jefferson Park Avenue
 FAX:   [phone]        Charlottesville, VA 22908











Received: from hopscotch.ksr.com by charon.cwi.nl with SMTP
    id AA01342 (5.65b/2.10/CWI-Amsterdam); Wed, 15 Jul 1992 07:13:01 +0200
Received: from ksr.com (frankenstein.ksr.com) by hopscotch.ksr.com with SMTP
    id AA07563; Wed, 15 Jul 1992 01:11:56 -0400
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA06450; Wed, 15 Jul 92 01:13:19 EDT
Received: by kaos.ksr.com (4.0/KSR-2.0)
    id AA26287; Wed, 15 Jul 92 01:13:17 EDT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Emacs/Python connection; and the future of Python
Date: Wed, 15 Jul 92 01:13:17 -0400
From: Tim Peters <[e-mail]>

>  ...
>  What do other people use interactive Python for?

Definitely not for a shell here either, Guido.  In the last week I used
an interactive Python (running in an Emacs py-mode buffer, of course
<grin>) for two new things:

1) Investigating the effect of various cache-design choices on the speed
   of some memory-access patterns common in scientific programs.

   This is a kind of mathematical modeling through simulation.
   Interactivity is a major attraction when doing this kind of stuff
   ("hmm, sure didn't expect that!  let's change this parameter & see
   what happens then ...").  My 2nd choice for this would be ABC (which
   also would have done a fine job on it), but my fingers will never
   "know" the ABC editor as well as they know Emacs -- and running in an
   Emacs buffer is the ultimate "history" mode.

2) Finding those integers N such that N*pi is closest to being exactly
   representable in the IEEE-754 64-bit format.

   Don't ask <grin -- it has to do with finding the worst cases for the
   argument-reduction phase of trig functions>.  This makes heavy
   demands on (very) large-integer arithmetic, and interactivity was
   useful mostly to run the program over a certain range, then
   progressively fiddle the routine to print less and less output as the
   numbers got larger & larger.  Interactivity was a convenience here,
   but not a necessity.

In both cases I'll echo something Steve M said:  these kinds of
exploratory applications tend to grow by leaps and bounds even while I'm
running them, and Python's design makes it amazingly easy to add new
code "on the fly" in a well-structured way (i.e., in a way that's not an
inherently incomprehensible mess the next day -- Python's clean module
structure, class gimmicks, and vrbls-are-local default all seem to play
a helpful part in this -- I'm not *exactly* sure how, though <0.6 grin>).

Unlike Steve, I never use Python for something that Perl can do in under
10 lines -- I may be unique in never using Python for "system" stuff.

so-it's-a-testament-to-the-language-that-even-i<grin>-am-delighted-
   with-it-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP
    id AA04328 (5.65b/2.10/CWI-Amsterdam); Wed, 15 Jul 1992 10:25:51 +0200
Received: by schelvis.cwi.nl with SMTP; Wed, 15 Jul 1992 08:25:50 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: sort() method
In-Reply-To: Message by [e-mail] ,
         Wed, 15 Jul 92 17:31:56 NZST , <[e-mail]>
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone](home)
X-Last-Band-Seen: Mucky Pup (Melkweg), Giant Family (Korsakoff, 8-7)
X-Mini-Review: MP: energetic dancepunkmetal. GF: retrorock. both: good.
Date: Wed, 15 Jul 1992 10:25:49 +0200
From: Jack Jansen <[e-mail]>

I don't think that having a built-in sort() with user-supplied compare
routine would be a big win when compared to programming sort yourself.
Calling out to the python code would probably loose you most of the
performance that programming in C would win you.

The only reasons I program some stuff I C are:
- features inaccessible from python (or difficult to access), like
  system calls or things involving hairy C structures, and
- manipulation of huge amounts of small data-items, like finding the
  average value of a sound sample (stored as byte values in a string).

The second case is why you want to program sort() in C, but if you
have to wrap each item as a python object and call out to a python
compare routine you loose the advantage.

A generic sort module in python should be peanuts, though. Anyone feel
like writing one?
--
Jack Jansen        | If I can't dance I don't want to be part of
[e-mail] | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Received: from ccvcom.aukuni.ac.nz by charon.cwi.nl with SMTP
    id AA01878 (5.65b/2.10/CWI-Amsterdam); Wed, 15 Jul 1992 07:54:04 +0200
Received: from mat.aukuni.ac.nz by aukuni.ac.nz; Wed, 15 Jul 92 17:32 +1200
Received: from matu12.mat.aukuni.ac.nz by mat.aukuni.ac.nz (4.1/SMI-4.1) id
 AA00771; Wed, 15 Jul 92 17:31:58 NZS
Date: Wed, 15 Jul 92 17:31:56 NZST
From: [e-mail]
Subject: sort() method
To: [e-mail]
Message-Id: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]

I am a newcomer to Python and as an exercise, I am converting some of
my Perl scripts into Python. So far I am satisfied with the result and
haven't had serious difficulties. In particular I like the nice and
*readable* look of my new scripts.

During this exercise, I observed that the Python module system
encouraged me to reorganize my, sometimes not too nice, Perl scripts
into a better structured (modularized) form.

I haven't used object-oriented features yet.

However the speed of my Python scripts are far from of the perl ones.
It doesn't really worry me at the moment and anyway, it could be
a consequence of my beginner Python programming style.

One of the problems I've encountered is that I frequently used the Perl
feature which allows the user to give his own comparing function as a
parameter to the sort routine. I couldn't find anything similar in
Python and therefore the equivalent Python code segment became more
complicated.

Is there any Python style way to work around this problem?

If there was no such a way, wouldn't it be worth to add this extension
in some way to the builtin sort() method? (I hope it is not a "perlis"
wish :-)

--
           ,
Peter Dobcsanyi











Replied: Thu, 06 Aug 1992 20:20:22 +0200
Replied: "Steven D. Majewski" <[e-mail]>
Received: from uvaarpa.Virginia.EDU by charon.cwi.nl with SMTP
    id AA26227 (5.65b/2.10/CWI-Amsterdam); Thu, 16 Jul 1992 00:07:53 +0200
Received: from aemsun.med.virginia.edu by uvaarpa.Virginia.EDU id aa25802;
          15 Jul 92 18:07 EDT
Received: by aemsun.med.Virginia.EDU (4.1/1.34)
    id AA18404; Wed, 15 Jul 92 18:05:34 EDT
Date: Wed, 15 Jul 92 18:05:34 EDT
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Mac Python


I never got much of a chance to work on PC-python -
I got switched over to some Mac programming jobs.

I assume that the Mac python doesn't support the Sockets module (True?).

I just managed to get the NCSA Sockect Library for MacTCP to compile
and build. ( For my current project. As soon as I have some free time
from that... ) I would like to re-build Mac Python with Sockets.

I have the Mac Python application that someone built previously.

Does anyone have a Makefile for MPW? ( or was Think C used? )

Any problems, tips, or changes known to compile on Mac.

Thanks,
 - Steve Majewski











Received: from hopscotch.ksr.com by charon.cwi.nl with SMTP
    id AA01741 (5.65b/2.10/CWI-Amsterdam); Thu, 16 Jul 1992 01:02:09 +0200
Received: from ksr.com (frankenstein.ksr.com) by hopscotch.ksr.com with SMTP
    id AA17083; Wed, 15 Jul 1992 19:01:01 -0400
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA12498; Wed, 15 Jul 92 19:02:26 EDT
Received: by kaos.ksr.com (4.0/KSR-2.0)
    id AA05142; Wed, 15 Jul 92 19:02:23 EDT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: sort() method
Date: Wed, 15 Jul 92 19:02:22 -0400
From: Tim Peters <[e-mail]>

>  ...
>  However the speed of my Python scripts are far from of the perl ones.

Depends on what you're doing ... e.g., at present, Perl is incomparably
faster at string searching, Python is incomparably faster at big-integer
arithmetic ...

>  ...
>  One of the problems I've encountered is that I frequently used the Perl
>  feature which allows the user to give his own comparing function as a
>  parameter to the sort routine. I couldn't find anything similar in
>  Python and therefore the equivalent Python code segment became more
>  complicated.
>
>  Is there any Python style way to work around this problem?

Note that Python does lexicographic sorting on tuples -- that is, the
first element of a tuple is used as the primary key, the second element
is the secondary key, and so on.  So, e.g.,

>>> a = [ ('a',9), ('b',2), ('aa',3), ('b',0) ]
>>> a.sort()
>>> a
[('a', 9), ('aa', 3), ('b', 0), ('b', 2)]
>>>

Note that the list is sorted by the first tuple component (the string),
and that "ties" are resolved by sorting on the second tuple component
(the integer -- that's why the two "('b',...)" entries were swapped).

Lexicographic sorting is powerful, so the usual trick in Python is to
create your data this way to begin with, or to create a temp list,
embedding your data in tuples of which the first component is of a
simple type (int or string) and whose values reflect the ordering you
want.

But that is clumsy, if you need to do it often.  If, e.g., I want to
sort the list above by the 2nd tuple components instead, I usually do
the more Perl-like

>>> def cmp_2nd_num( (dummy1, n1), (dummy2, n2) ) : return n1 - n2
...
>>> sort_by_2nd_num = make_sorter( cmp_2nd_num )
>>> sort_by_2nd_num( a )
[('b', 0), ('b', 2), ('aa', 3), ('a', 9)]
>>>

"make_sorter" is a function that takes a (Perl-like) comparison function
as argument, and returns a sorting function that sorts a list according
to the comparison function.  I'll attach Python code for "make_sorter"
below; it's not intended to be industrial-strength (to the contrary, it
can be very wasteful of both time & space); I simply use this way for
convenience.  Replace it with something smarter ...

>  ...
>  If there was no such a way, wouldn't it be worth to add this extension
>  in some way to the builtin sort() method?

Well, if you're running Python then I'd guess you have the source code
for it:  it is "worth it" to *you* to add this extension <grin>?

master-of-unfair-questions-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]

Following is one way to code up the `make_sorter' function used above:

class Sorter:
    def init( self, cmp ):
    self.Cmp = cmp
    return self

    def sort( self, list ):
    # simple quicksort
    if len(list) <= 1: return list

    key = list[0]
    less, same, greater = [], [], []
    for thing in list:
        outcome = self.Cmp( thing, key )
        if   outcome < 0: which = less
        elif outcome > 0: which = greater
        else:          which = same
        which.append( thing )

    return self.sort(less) + same + self.sort(greater)

def make_sorter( cmp ):
    # return a sorting function that sorts a list according to comparator
    # function `cmp'
    # cmp(a,b) should return < 0 if a < b
    #                 = 0 if a = b
    #                 > 0 if a > b
    return Sorter().init( cmp ).sort

>>> END OF MSG










Replied: Thu, 30 Jul 1992 21:38:32 +0200
Replied: "[e-mail] "
Received: from ccvcom.aukuni.ac.nz by charon.cwi.nl with SMTP
    id AA09598 (5.65b/2.10/CWI-Amsterdam); Thu, 16 Jul 1992 07:07:58 +0200
Received: from mat.aukuni.ac.nz (matu1.mat.aukuni.ac.nz) by aukuni.ac.nz (PMDF
 #2864 ) id <[e-mail]>; Thu, 16 Jul 1992 16:42:27 +1200
Received: from matu12.mat.aukuni.ac.nz by mat.aukuni.ac.nz (4.1/SMI-4.1) id
 AA02219; Thu, 16 Jul 92 14:16:42 NZS
Date: 16 Jul 1992 14:16:40 +1200 (NZST)
From: [e-mail] (Peter Dobcsanyi)
Subject: Re: sort() method
In-Reply-To: <[e-mail]>; from "Jack Jansen" at Jul
 15, 92 10:25 am
To: [e-mail]
Message-Id: <[e-mail]>
X-Envelope-To: [e-mail]
Content-Transfer-Encoding: 7BIT
X-Mailer: ELM [version 2.3 PL11]

Jack Jansen writes:
> I don't think that having a built-in sort() with user-supplied compare
> routine would be a big win when compared to programming sort yourself.
> Calling out to the python code would probably loose you most of the
> performance that programming in C would win you.

To be more precise, I did not think of writing any external C (or
whatever else other language) routine. What I meant is something like
that:

    def my_compare(x,y)
    if x <my_less> y    : return -1
    if x <my_equal> y    : return 0
    if x <my_greater> y    : return 1

    ......
    # then I could say

    foo_list.sort(my_compare)


> A generic sort module in python should be peanuts, though. Anyone feel
> like writing one?

Maybe this is the solution, but (being a beginner) I cannot see how can
one refine the *built-in* sort() method on Python level.

Could anyone, please, give some general idea about the mentioned
"peanuts".

--
           ,
Peter Dobcsanyi










Received: from uu.psi.com by charon.cwi.nl with SMTP
    id AA23891 (5.65b/2.10/CWI-Amsterdam); Fri, 17 Jul 1992 17:49:46 +0200
Received: from midas.UUCP by uu.psi.com (5.65b/4.1.031792-PSI/PSINet)
    id AA22568; Fri, 17 Jul 92 11:05:51 -0400
Received: from lynchpin.mtkgc.com by mtkgc.COM (4.1/SMI-4.1)
    id AA18091; Fri, 17 Jul 92 09:43:54 EDT
Received: by lynchpin.mtkgc.com (4.1/SMI-4.1)
    id AA07027; Fri, 17 Jul 92 09:48:15 EDT
Date: Fri, 17 Jul 92 09:48:15 EDT
From: [e-mail] (Kevin Samborn)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: What do I use python for?  ( A testimonial! )

I this is what have used Python for:

A dialog manager for a user interface management tool (with Motif).
Python was inserted at the point that XtCallbacks were called, and the
python code was executed instead...

I wrote simple interfaces to the Xt widgets, and was able to do quite
a bit, including calling the original callbacks if necessary.

Now I am considering doing the same thing for OpenLook (OLIT).

kevin samborn
--
kevin samborn
[e-mail]










Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA16550 (5.65b/2.10/CWI-Amsterdam); Mon, 20 Jul 1992 18:49:11 +0200
Received: from stun4b.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA13659; Mon, 20 Jul 92 09:46:53 PDT
Date: Mon, 20 Jul 92 09:46:53 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4b.cs.caltech.edu (4.1/SMI-4.1)
    id AA05788; Mon, 20 Jul 92 09:49:10 PDT
To: [e-mail]
Cc: [e-mail]
Subject: graphics question: how to get the text of a TextEdit widget
Comments: Hyperbole mail buttons accepted, v3.02P.

I was able to create a TextEdit widget and put text in it by:

t = TextEdit.TextEdit().createboxed(group, (3,1),(2,2))
t.settext('howdy ho')

but t.text yields no string

any ideas why ?

--
terrence brannon
[e-mail]











Replied: Thu, 30 Jul 1992 21:49:28 +0200
Replied: "[e-mail] (Terrence M. Brannon) "
Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA14158 (5.65b/2.10/CWI-Amsterdam); Tue, 28 Jul 1992 19:05:34 +0200
Received: from stun4q.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA06971; Tue, 28 Jul 92 10:02:15 PDT
Date: Tue, 28 Jul 92 10:02:15 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4q.cs.caltech.edu (4.1/SMI-4.1)
    id AA17925; Tue, 28 Jul 92 10:05:31 PDT
To: [e-mail]
Cc: [e-mail]
Subject: repeated C-c will cause a window to fail to close
Comments: Hyperbole mail buttons accepted, v3.02P.
Note: C-c means control-c

Has anyone created a window in the stdwin module of python and not
been able to get it to close because you sent a series of C-c at
the Python interpreter?

I am using C-c from Emacs as a signal to the python interpreter that
emacs has finished what it has requested like so:



    python interp -- calls emacs lisp----> emacs does function ---|
                                       |
                     python     <------    sends C-c<------
                    continues    python interp
                            process to signal
                            completion

Python does its wait by doing a try:
                    emacs.dired('.')
                except:
                    print 'emacs is finished'

--
terrence brannon
[e-mail]











Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP
    id AA12486 (5.65b/2.10/CWI-Amsterdam); Wed, 29 Jul 1992 10:30:42 +0200
Received: by schelvis.cwi.nl with SMTP; Wed, 29 Jul 1992 08:30:31 GMT
Message-Id: <[e-mail]>
To: [e-mail] (Terrence M. Brannon)
Cc: [e-mail]
Subject: Re: repeated C-c will cause a window to fail to close
In-Reply-To: Message by [e-mail] (Terrence M. Brannon) ,
         Tue, 28 Jul 92 10:02:15 PDT , <[e-mail]>
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone](home)
X-Last-Band-Seen: Some have Fins (Paradiso, 25-7)
X-Mini-Review: I like loud bands, but this was ridiculous. Fled after 5 mins.
Date: Wed, 29 Jul 1992 10:30:30 +0200
From: Jack Jansen <[e-mail]>

Terrence,
I don't fully understand what you mean. The stdwin window doesn't
react to the 'close' menu? Or doesn't it react to deleting the object?

Hmm.... I'm just think of something, wait a minute... Yes! There is
some sort of cyclic reference in stdwin that occasionally causes
windows to stay around when you think they are deleted. For that
reason, there is also an explicit 'close()' method on stdwin windows.
Maybe this is what you're looking for (although it has little to do
with emacs and ^C)?
--
Jack Jansen        | If I can't dance I don't want to be part of
[e-mail] | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA07119 (5.65b/2.10/CWI-Amsterdam); Thu, 30 Jul 1992 01:56:32 +0200
Received: from stun4q.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA11219; Wed, 29 Jul 92 16:52:22 PDT
Date: Wed, 29 Jul 92 16:52:22 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4q.cs.caltech.edu (4.1/SMI-4.1)
    id AA18522; Wed, 29 Jul 92 16:55:45 PDT
To: [e-mail]
Subject: Something TextEdit.py needs
Comments: Hyperbole mail buttons accepted, v3.02P.


it has a settext method but no gettext method .

i added one myself because i needed it . here it is :

def gettext(self):
    self.editor.gettext()


love ,

Terrence Brannon -- [e-mail]











Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA00149 (5.65b/2.10/CWI-Amsterdam); Thu, 30 Jul 1992 21:38:29 +0200
Received: by voorn.cwi.nl with SMTP; Thu, 30 Jul 1992 19:38:34 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: sort() method
In-Reply-To: Your message of "16 Jul 1992 14:16:40 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 30 Jul 1992 21:38:33 +0200
Sender: [e-mail]

Here are some comments on the issue of a proposed extension to
list.sort() (an optional comparison function that determines how the
elements of a list are to be compared).

There's nothing wrong with this wish, and it has come up before
(although I wouldn't call it perl-ish but C-ish, see qsort(3)).

The value of such an extension, however, is limited, and usually
the alternative method suggested by Tim Peters is better: create a
temporary list containing tuples containing some function of the items
to be compared that determines the right ordering.  E.g., to sort
strings independent of case, create a list containing tuples with the
string converted to lowercase first and the original string second,
and sort this list.

I'll try to explain why I think this way of sorting is better in many
cases.

Doing the equivalent in C would be wasteful of space and probably not
significantly faster than a cleverly-coded version that does the
lowercase conversion on the fly.  However, the situation in Python is
different.  True, we are wasting some space, but we are gaining speed,
since a "cleverly-coded" comparison function in Python has to be much
slower than Python's built-in tuple or string comparison operation.
(In general, many techniques for "clever coding" in C don't work in
Python because the relative speed of operations are vastly different.)

Knuth tells us that sorting takes at least, roughly, N log2 N
comparisons.  Using the "comparison-function" method to sort a
1000-item list would mean roughly 10000 calls to this function, and
thus 20000 calls to string.lower().  On the other hand, the "temp
list" method would require only 1000 calls!

There are, however, situations in which the ordering of items is not
easily converted to an equivalent ordering on some function of the
items, while comparing any two items would be a piece of cake.  A
specia case, not unimportant for Python, is the situation of a
user-defined class whose objects have a cmp() method.

It is easy to add an optional comparison function to list.sort() now,
so that I might just do that.  (Maybe it wasn't so easy when I wrote
the original code; calling Python back from C is a "recent" addition
to the tools available to the extension writer.)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Oh, so you want to fly an AEROPLANE?"










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA00658 (5.65b/2.10/CWI-Amsterdam); Thu, 30 Jul 1992 21:49:59 +0200
Received: by voorn.cwi.nl with SMTP; Thu, 30 Jul 1992 19:50:02 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: repeated C-c will cause a window to fail to close
In-Reply-To: Your message of "Tue, 28 Jul 1992 10:02:15 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 30 Jul 1992 21:50:01 +0200
Sender: [e-mail]

>Has anyone created a window in the stdwin module of python and not
>been able to get it to close because you sent a series of C-c at
>the Python interpreter?

There's a problem with Python's STDWIN interface and C-c that might
explain your problem.  When the Python code calls stdwin.getevent(),
interrupt signals sent to the Python interpreter are postponed until
this function returns an event, and then not always handled
adequately.  Unfortunately, it would require a significant redesign of
the underlying STDWIN library and interface to fix this (simply
long-jumping out of the underlying wgetevent() call might leave the
internal administration of STDWIN or of the under-under-lying X11 or
Mac window system in a bad state).

I suggest that you redesign your code to avoid using signals (that's
better anyway, for various reasons), e.g. the Emacs code could always
send a line of input to the Python process when it is finished, and
the Python interface could wait for this line.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"May your mailbox overflow with messages" (modern Chinese curse)










Replied: Sat, 01 Aug 1992 01:54:15 +0200
Replied: [e-mail]
Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA13593 (5.65b/2.10/CWI-Amsterdam); Fri, 31 Jul 1992 21:16:35 +0200
Received: from stun4r.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA14940; Fri, 31 Jul 92 12:13:00 PDT
Date: Fri, 31 Jul 92 12:13:00 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4r.cs.caltech.edu (4.1/SMI-4.1)
    id AA07442; Fri, 31 Jul 92 12:16:38 PDT
To: [e-mail]
Subject: unexpect behavior from my added method
Comments: Hyperbole mail buttons accepted, v3.02P.

I need to read the value that the user inputs into a TextEdit widget.
lib/TextEdit.py in the Python distribution does not have a gettext()
method only a settext() method, so I wrote the following:

def gettext(self):
    self.editor.gettext()

However instead of just getting the text of the TextEdit widget, I get
the word None also. IN other words if the user has input as 12 into
the TextEdit widget and afterwards I do this:

tmp = [text_edit_widget.gettext()]
print tmp[0]

the output is:

'12'
None



Instead of just '12' as I would think that it should be

love ,

Terrence Brannon -- [e-mail]











Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA28633 (5.65b/2.10/CWI-Amsterdam); Sat, 1 Aug 1992 01:54:08 +0200
Received: by voorn.cwi.nl with SMTP; Fri, 31 Jul 1992 23:54:14 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: unexpect behavior from my added method
In-Reply-To: Your message of "Fri, 31 Jul 1992 12:13:00 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Sat, 01 Aug 1992 01:54:14 +0200
Sender: [e-mail]

Terence Brannon writes:

>def gettext(self):
>    self.editor.gettext()

and wonders why it doesn't work (it prints the value but returns
None).

Try this instead:

def gettext(self):
    return self.editor.gettext()

This probably belongs in the FAQ: any expression that doesn't evaluate
to "None" is printed when executed as a statement.  This is useful
when using Python as an interactive calculator.  I left it in for
non-interactive statements: partly to simplify the interpreter (it's
not always easy to figure out whether a statement is executed
interactively; partly for consistency (a statement's effect is the
same interactively or in a function); partly to force programmers to
think about what to do with function return values.  If you don't want
to use a value returned by a function you have to assign it to a dummy
variable.  If you want to return it, you must use a return statement.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I don't care how excrementally runny it is, hand it over with all speed!"










Replied: Tue, 04 Aug 1992 10:59:13 +0200
Replied: "[e-mail] (Python Mailing List) "
Received: from ccvcom.aukuni.ac.nz by charon.cwi.nl with SMTP
    id AA07526 (5.65b/2.10/CWI-Amsterdam); Tue, 4 Aug 1992 10:25:42 +0200
Received: from mat.aukuni.ac.nz (matu1.mat.aukuni.ac.nz) by aukuni.ac.nz (PMDF
 #2864 ) id <[e-mail]>; Tue, 4 Aug 1992 11:05:08 +1200
Received: from matu12.mat.aukuni.ac.nz by mat.aukuni.ac.nz (4.1/SMI-4.1) id
 AA00933; Tue, 4 Aug 92 11:04:34 NZS
Date: 04 Aug 1992 11:04:32 +1200 (NZST)
From: [e-mail] (Peter Dobcsanyi)
Subject: Bug!?
To: [e-mail] (Python Mailing List)
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7BIT
X-Mailer: ELM [version 2.3 PL11]

I accidentally found the following strange behavior:

PYTHON SCRIPT:

    #!/usr/local/bin/python
    #

    import string

    x = string.atoi('01')
    print x

    x = string.atoi('07')
    print x

    x = string.atoi('08')
    print x


RESULT:

1
7
SyntaxError: invalid syntax
Stack backtrace (innermost last):
  File "p", line 12
    x = string.atoi('08')
  File "/usr/local/lib/python/string.py", line 110
    return eval(str)


INTERACTIVE:

    % python
    Python 0.9.6 (>= 1 Jan 1992).
    Copyright 1990, 1991, 1992 Stichting Mathematisch Centrum, Amsterdam
    >>> import string
    >>> x = string.atoi('07')
    >>>

    Python 0.9.6 (>= 1 Jan 1992).
    Copyright 1990, 1991, 1992 Stichting Mathematisch Centrum, Amsterdam
    >>> import string
    >>> x = string.atoi('08')
    SyntaxError: invalid syntax
    Stack backtrace (innermost last):
      File "<stdin>", line 1
      File "/usr/local/lib/python/string.py", line 110
    return eval(str)
    >>>

--
           ,
Peter Dobcsanyi










To: [e-mail] (Python Mailing List)
Subject: Re: Bug!?
In-reply-to: Your message of "04 Aug 1992 11:04:32 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 04 Aug 1992 10:59:14 +0200
Sender: guido

Peter Dobcsanyi writes:
>I accidentally found the following strange behavior:
[...]
>    x = string.atoi('08')
[...]
>SyntaxError: invalid syntax

Yeah, string.atoi() internally calls eval(), which interprets this as
an illegal octal number.  According to the documentation string.atoi()
is not supposed to handle octal numbers, so I'll fix it.  (Would this
break anybody's code?)

Here is what I believe is a fixed version of string.atoi():

# Convert string to integer
atoi_error = 'non-numeric argument to string.atoi'
def atoi(str):
    sign = ''
    s = str
    if s[:1] in '+-':
        sign = s[0]
        s = s[1:]
    if not s: raise atoi_error, str
    while s[0] == '0' and len(s) > 1: s = s[1:]
    for c in s:
        if c not in digits: raise atoi_error, str
    return eval(sign + s)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Are all your pets called Eric?"










Received: from ben.uknet.ac.uk by charon.cwi.nl with SMTP
    id AA01550 (5.65b/2.10/CWI-Amsterdam); Tue, 4 Aug 1992 18:28:16 +0200
Received: from eros.uknet.ac.uk by ben.uknet.ac.uk via UKIP with SMTP (PP)
          id <[e-mail]>; Tue, 4 Aug 1992 16:16:52 +0100
Received: from camscan.co.uk by eros.uknet.ac.uk with UUCP
          id <[e-mail]>; Tue, 4 Aug 1992 16:16:47 +0100
Received: from electra.camscan.co.uk by star.camscan.co.uk;
          Tue, 4 Aug 92 15:33:13 BST
From: Gerry Stringer <[e-mail]>
Date: Tue, 4 Aug 92 15:33:16 BST
Message-Id: <[e-mail]>
To: [e-mail]
Subject: interface generation



Hello,

Question: has anyone automated/semi-automated generation of Python
interface code (ideally for C++) before I think about having a go?

Waffle for your interest: my company's application involves collecting
X-ray data in the form of spectra from a box attached to an electron
microscope and then displaying it, analysing what elements it contains
etc.

We've actually designed the software as closely cooperating multiple
processes rather than some monolith eg. one process holds and displays
spectra while another controls acquiring it, another process analyses
it etc.

We write in C++ and have developed our own C++ library called RMC
(Remote Method Call) so that eg. object.dosomething(arg1,arg2) while
appearing to run locally, actually does the equivalent of RPC ie.
packaging args, executing code in another process, unpackaging
results.

To stop terminal boredom typing in code, we have "rmcgen" which takes a
classname, methods and their args and generates the C++ to interface to
RMC. It is this, or a Postgres preprocessor I developed, that I would
probably use as the starting point for Python interface generation.

We have an OPENWINDOWS GUI front end to all this but we still need an
interpreter (for a different sort of translation?) to automate tasks at
a high level hence Python.

Many thanks again to Guido who advised me about how to have a single
common shared library of core Python code with process specific
modules.

        gerry

+--------------------------------+---------------------------------+
|Gerry Stringer                  |Phone: [phone]            |
|Cambridge Scanning Company Ltd  |Fax:   [phone]            |
|Saxon Way                       |UUCP : [e-mail]       |
|Bar Hill                        |       [e-mail]        |
|Cambridge CB3 8SL               |                      |
|United Kingdom                  |                                 |
+--------------------------------+---------------------------------+










Replied: Tue, 04 Aug 1992 21:49:09 +0200
Replied: "python-list "
Replied: Tue, 04 Aug 1992 21:46:56 +0200
Replied: "Jaap Vermeulen <[e-mail]> "
Received: from gateway.sequent.com by charon.cwi.nl with SMTP
    id AA04852 (5.65b/2.10/CWI-Amsterdam); Tue, 4 Aug 1992 21:31:03 +0200
Received: from eng2.sequent.com by gateway.sequent.com (5.61/1.34)
    id AA19901; Tue, 4 Aug 92 12:31:22 -0700
Received: by eng2.sequent.com (5.65/1.34)
    id AA23469; Tue, 4 Aug 92 12:28:28 -0700
Message-Id: <[e-mail]>
To: Python Mailing List <[e-mail]>
Subject: How do I get to the local dictionary in a function?
Priority: Normal
Precedence: first-class
Organization: Sequent Computer Systems, Inc.
          Decision Support Group - MailStop: RHE2-358
          15450 S.W. Koll Parkway
          Beaverton, OR  97006
X-Phone: [phone]
X-Fax: [phone]
X-Uucp: ...!uunet!sequent!jaap
X-Internet: [e-mail]
X-Face: C4Cnai$>Eja5I6Vq?(gdN#SXX#`-XgAnmUn&e54sx7@1>q@vkrd_XnH![P>w.:7IJJ;{Bts
 WJd)u&G!V}0OR?2o5cUgIY}.T{g]PMC=*~]3n_t)S-ZkC(WG}3:#hcA6Oazx:}yc&k,hsF7D},7x>l
 nyfRjO7$@]fHBN>aC9-M3pKfbYHiy!PWD{_bx~fo})b4tU.;Ao%x[upCI,
Date: Tue, 04 Aug 92 12:28:27 PDT
From: Jaap Vermeulen <[e-mail]>


I would like to pass along the local namespace (dictionary) of a function
into an exec() statement.  Either I'm overlooking something or it is
buried somewhere in the manual since I can't seem to find how to do that.
I can get to the global namespace, but not the local.

The problem is that I want to specify the global namespace explicitly.
This defaults to the local namespace being the global namespace, which
is exactly what I do *not* want.

Anybody any clues?

Example:

    >>> global_namespace = {}

    >>> def showit:
    ...     var_in_local_namespace = 0
    ...     # I wish I could give the local namespace as third argument
    ...     exec ('var_in_local_namespace = 1\n', global_namespace)
    ...     return var_in_local_namespace

    >>> showit()
    0
    >>>

Thanks,

    -Jaap-
--
Jaap Vermeulen                    +--------------------------+
                        | Sequent Computer Systems |
    Internet : [e-mail]        | Beaverton, Oregon       |
    Uucp     : ...uunet!sequent!jaap    +--------------------------+










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA05243 (5.65b/2.10/CWI-Amsterdam); Tue, 4 Aug 1992 21:49:03 +0200
Received: by voorn.cwi.nl with SMTP; Tue, 4 Aug 1992 19:49:09 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: How do I get to the local dictionary in a function?
In-Reply-To: Your message of "Tue, 04 Aug 1992 12:28:27 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 04 Aug 1992 21:49:09 +0200
Sender: [e-mail]

Jaap Vermeulen writes:
>I would like to pass along the local namespace (dictionary) of a function
>into an exec() statement.  Either I'm overlooking something or it is
>buried somewhere in the manual since I can't seem to find how to do that.
>I can get to the global namespace, but not the local.

You cannot do that, and in a future version of Python the local
namespace of a function may not be implemented as a dictionary.
I played a little with implementing it as a mutable tuple, indexed by
variable number, and it makes an awful lot of difference in execution
speed.  (Unfortunately there are a lot of minor things to be cleared up
before this can be used in general, and it won't be in the next
release.)

Why do you the want to access local namespace?

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Do you want to have just one argument or were you thinking of taking
a course?"
[Sorry for the duplicate message Jaap, I must train my fingers :-) ]










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA16027 (5.65b/2.10/CWI-Amsterdam); Mon, 10 Aug 1992 23:50:08 +0200
Received: by voorn.cwi.nl with SMTP; Mon, 10 Aug 1992 21:50:14 GMT
Message-Id: <[e-mail]>
To: Jaap Vermeulen <[e-mail]>
Cc: Python Mailing List <[e-mail]>
Subject: Re: Observations about dbm
In-Reply-To: Your message of "Mon, 10 Aug 1992 09:32:30 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 10 Aug 1992 23:50:13 +0200
Sender: [e-mail]

>This one is for Jack: I was using the dbm module and am a little
>disappointed that it only takes strings as data (although I shouldn't look
>a gift horse in the mouth :-). I was wondering how much effort it would
>be to support all data types that are supported by the module 'marshal'?

Actually, this was done on purpose.  With the current set-up you can
share databases between C programs and Python code.  If you want to
store arbitrary Python values in a database, just place them between
`reverse quotes` when putting them in and pass them through eval()
after taking them out.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Eric, being such a happy cat, was a piece of cake."










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA16036 (5.65b/2.10/CWI-Amsterdam); Mon, 10 Aug 1992 23:56:56 +0200
Received: by voorn.cwi.nl with SMTP; Mon, 10 Aug 1992 21:57:03 GMT
Message-Id: <[e-mail]>
To: Jaap Vermeulen <[e-mail]>
Cc: Python Mailing List <[e-mail]>
Subject: Re: Observations about types
In-Reply-To: Your message of "Mon, 10 Aug 1992 09:32:30 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 10 Aug 1992 23:57:02 +0200
Sender: [e-mail]

>On another noter: I was trying to do some reasonable type checking in
>some routines I was writing for a stress test harnass. The problem is
>that type() only returns the generic type, not the specific type. I.e.
>if I have an instance of class 'foo', type(instance) will say <type
>'instance'>, but not <type 'instance foo'> or so.

True, but for class instances you can access the "secret" attribute
__class__ to get at the class.

For many other purposes of type checking you also need much more
information than what type() returns; e.g. in many situations tuples
of different length should be considered different types, and the
types of the items should be considered as well.  Luckily it isn't too
hard to write a function that returns a unique string with the
required properties -- type() is just a low-level tool to be used by
such a function.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I told you.  We're an anarcho-syndicalist commune."










Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP
    id AA08968 (5.65b/2.10/CWI-Amsterdam); Tue, 11 Aug 1992 11:46:29 +0200
Received: by schelvis.cwi.nl with SMTP; Tue, 11 Aug 1992 09:46:29 GMT
Message-Id: <[e-mail]>
To: Jaap Vermeulen <[e-mail]>
Cc: Python Mailing List <[e-mail]>
Subject: Re: Observations about instances, types and dbm
In-Reply-To: Message by Jaap Vermeulen <[e-mail]> ,
         Mon, 10 Aug 92 09:32:30 PDT , <[e-mail]>
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone](home)
X-Last-Band-Seen: Rythm Pigs (Melkweg, 5-8)
X-Mini-Review: Lame.
Date: Tue, 11 Aug 1992 11:46:28 +0200
From: Jack Jansen <[e-mail]>


Recently, Jaap Vermeulen <[e-mail]> said:

    This one is for Jack: I was using the dbm module and am a little
    disappointed that it only takes strings as data (although I shouldn't look
    a gift horse in the mouth :-). I was wondering how much effort it would
    be to support all data types that are supported by the module 'marshal'?

Hmm, I'm not too sure about this. An ideal solution would be if you
could write a wrapper in python to do this, but that is currently
impossible. Guido, would it be possible to extend python to allow you
to declare classes that mimic builtin types? I can envision a model
whereby the builtin class Mapping() defines methods get(index) and
put(index, value), and where I can then define a class that inherits
Mapping() and redefines get() and put(). The parser should then
translate 'foo[expr]' into 'foo.get(expr)' and that's that.

But then, I'm probably seeing things in a far too simple way...
--
Jack Jansen        | If I can't dance I don't want to be part of
[e-mail] | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA20623 (5.65b/2.10/CWI-Amsterdam); Thu, 13 Aug 1992 11:36:17 +0200
Received: by voorn.cwi.nl with SMTP; Thu, 13 Aug 1992 09:36:24 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Minor bug, perhaps? + (PC-Python/CS1)
In-Reply-To: Your message of "13 Aug 1992 10:27:22 MET."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 13 Aug 1992 11:36:23 +0200
Sender: [e-mail]

Stoffel,

Glad to hear your opinion about Python's "teachability"!

Regarding your problem I was afraid this would happen some day!

>Here we have an assignment statement following directly on a `one-line' if:
>        ...
>        if i==n: break
>        j = i
>        ...

Looking carefully at your example, there are 8 spaces before the "if",
but two tabs before the "j = i" line.  (I'm glad that e-mail doesn't
mess with tabs, most of the time!)  In my source, both lines begin
with two tabs.  So I suspect that you've been editing the file in an
editor that believes in 4 spaces per tab and somehow the editor
decided to replaces the tabs on the first line by the "equivalent"
number of spaces (e.g. because you touched the line with the cursor).

There are several ways to fix this:

(0) Find a clean backup of the library files with all the tabs in
them.  (This is probably necessary anyway, to avoid surprises.)

(1) Change your editor's idea of tab size (this may or may not be
possible).

(2) Replace all tabs by a consistent number of spaces, and never use
tabs when editing.  Now it doesn't matter how many spaces you use as
long as you are consistent (Python doesn't require indented lines to
be indented by a specific number of spaces, as long as you are
consistent.)  The function expandtabs() in string.py shows how to do
this in Python.

(3) Use an undocumented feature of the Python interpreter which
changes Python's idea of how many spaces a tab is worth: in the
beginning of each file, insert a comment of the form

    # vi:set tabsize=N:

where N is the desired tab size (e.g. 4).


Note that if you *only* use spaces for indentation you never run into
trouble; if you *only* use tabs, it likewise can't go wrong; but if
you start mixing the two, it's important that your editor and Python
have the same idea of tab size.  There should probably be a command
line option to set the interpreter's default tab size (in fact on the
Mac the default is 4 because all editors there use that default...).

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"You are all individuals!" "We are all individuals!"










Replied: Thu, 13 Aug 1992 11:36:22 +0200
Replied: "python-list "
Received: from cd4380.ufh.ac.za by charon.cwi.nl with SMTP
    id AA19141 (5.65b/2.10/CWI-Amsterdam); Thu, 13 Aug 1992 10:31:35 +0200
Received: from csgate.ufh.ac.za by cd4380.ufh.ac.za (5.61/1.34)
    id AA28342; Thu, 13 Aug 92 06:29:38 -0200
Received: From FS2/WORKQUEUE by csgate.ufh.ac.za
          via Charon 3.4 with IPX id 100.920813102735.320;
          13 Aug 92 10:26:56 -0200
Message-Id: <[e-mail]>
To: [e-mail]
From: "Stoffel Erasmus"  <[e-mail]>
Date:         13 Aug 92 10:27:22 GMT+200
Subject:      Minor bug, perhaps? + (PC-Python/CS1)
X-Mailer:     Pegasus Mail v2.3 (R2).

Guido,

We decided that, being 3/5 thru the year, a bit of bi-linguality won't
do our CS1's any harm.  We have thus started moving from ABC to Python
(and back).  To me it is quite an exhilirating experience --- working
out `cheat sheets' to help them with translating, etc.  We'll expect
them to transliterate some of the code segments in the ABC Handbook as
well.  Python's `teachability' is being confirmed by this exercise, IMHO.
(CS1 is writing the first ABC vs Python test tomorrow morning.)

We are using PC-Python, and thus had to rediscover the usefulness of the
`raw' DOS command-line-editing function keys (F1..F6).  Otherwise I'm
using QuickEdit as a front end to the interpreter.

There is one small fly (bug?) in the ointment though!  When we try to
import the `string' module, the following happens:

Parsing error: file K:\Python\Lib\string.py: line 60:
               j = i
               ^
Syntax error: invalid syntax

Here we have an assignment statement following directly on a `one-line' if:
        ...
        if i==n: break
        j = i
        ...

What makes me suspicious is the fact that I encounter a similar problem
in the following code segment:

        from math import sqrt

        def smallest_divisor(n):
           if (n % 2 == 0): return 2
           try = 3
           while try <= sqrt(n):
              if n % try == 0: return try
              try = try+2
              ^
           return n

        print smallest_divisor(287)

Is there a work-around perhaps?

If anybody on the Python-list is interested in criticizing some of my
efforts, I would be quite happy to exhange ideas & handouts.

Regards,

Stoffel.











Replied: Fri, 14 Aug 1992 10:56:32 +0200
Replied: "[e-mail] (Terrence M. Brannon) "
Received: from jove.cs.caltech.edu by charon.cwi.nl with SMTP
    id AA00264 (5.65b/2.10/CWI-Amsterdam); Thu, 13 Aug 1992 19:12:19 +0200
Received: from stun4s.cs.caltech.edu by jove.cs.caltech.edu (4.1/1.34.1)
    id AA07358; Thu, 13 Aug 92 09:49:38 PDT
Date: Thu, 13 Aug 92 09:49:38 PDT
From: [e-mail] (Terrence M. Brannon)
Message-Id: <[e-mail]>
Received: by stun4s.cs.caltech.edu (4.1/SMI-4.1)
    id AA02428; Thu, 13 Aug 92 09:50:19 PDT
To: [e-mail]
Subject: Python FAQ
Comments: Hyperbole mail buttons accepted, v3.02P.

This version of the FAQ will be released to Usenet after I hear your
comments. I am out of town until Monday so I wont get back to you
until then.

* Menu:

* Introduction::        Introduction
* Trivia::            Trivia
* Overview of Available Modules::  Overview of Available Modules
* Common Questions::
* Advanced Questions::        Advanced Questions
* Additional Information::
* Obtaining::            Obtaining


Introduction
************

Welcome to the Python Frequently Asked Questions List. This list is
maintained by a neophyte to Python and its purpose is to serve as a
reference source for questions that I have had as a beginner that
others will most likely have also.

In case you don't know what Python is, it is an object-oriented,
extensible, interpreted programming language that bridges the gap
between C and shell prorgramming and is thus ideally suited for
"throw-away" programming and rapid prototying but has also been used for
major software development.

It competes well with TCL, Perl and Emacs Lisp - three popular
feature-packed interpreted languages. Among its strong points:

   * The STDWIN class which allows the programmer to use generic graphics
     requests and events so that programs are immediate portable to
     X-Windows, Macintosh, Atari ST, and IBM PC.
   * The regular expression module allows for easy string manipulation.
   * Extensible through the development of new classes or new modules.
   * Python routines are calling from the C programming language as well as
     experimentally from Emacs Lisp.

The latest version of the Python FAQ is available by contacting the
author. Requests for the latest version or any other suggestions should
be sent to [e-mail]

Email [e-mail] for details about the League for Programming
Freedom.

Trivia
******


The Author
==========
The author of Python, Guido van Rossum, received a Master's degree in
mathematics and
computer science from the University of Amsterdam in 1982.  He has
since been employed by CWI, a government-sponsored research institute
in the Netherlands employing about 200 people.  CWI's research themes
include large areas of computer science and mathematics, pure as well
as applied.  Guido has been involved in several projects at CWI: the
design and implementation of ABC, a programming language and
environment for programming by non-expert users, and the Amoeba
project, a highly advanced distributed operating system developed
jointly with the Free University of Amsterdam.  In 1991 he joined a
newly formed multimedia research project at CWI, which is
investigating issues of synchronization of independent data streams,
as well as operating support and user interfaces for multimedia
applications.  In his "spare time" he developed several freely
available software packages such as STDWIN, a library for portable use
of windowing interfaces and Python, an interpreted prototyping and
scripting language.  He can be reached electronically at [e-mail].

(If you want to summarize his current work and interests in one word,
"multimedia" would be it.)


Since he named the programming language Python, he obviously likes to
watch Monty Python programs.

He also has some sort of program that automatically generates curious
quotes. Some of the quirkiest:

     --Guido van Rossum, CWI, Amsterdam <[e-mail]>
     "Kemal Ataturk had an entire menagerie called Abdul"

     --Guido van Rossum, CWI, Amsterdam <[e-mail]>
     "Did you say knives?"
     "Rotating knives, yes"

     --Guido van Rossum, CWI, Amsterdam <[e-mail]>
     "Repo Man's got all night, *every* night"

The Language
============

   * The language is named after Monty Python, not a reptile.
   * There are two operators to test for inequality `<>' and `!='
     because Guido could not figure which he liked best

Overview of Available Modules
*****************************

For each type of module (built-in, standard, etc.) an exhaustive listing
of modules is not given. Instead, the more powerful and useful ones are
listed in order to whet your appetite for Python.


Built-In Modules
================

regex
-----

The `regex' module allows you to set up configurable regular
expressions which by default uses Emacs-style matching. For more info
on denoting literal characters in Python see *Note Common Questions::.

marshal
-------

The `marshal' module allows you to write Python values in a
machine-independant format so that a program which writes data to a file
will port across architectures

Standard Modules
================

string
------

Although there are a host of string operations available, the most
salient ones are listed below:

   * String splitting based on a string. No string splitting based on a
     regexp. Given the string `'Bill Jones:2424 Klickitat St.:Iceland'' we
     can create a list of the colon-separated fields as follows:
          string.split('Bill Jones:2424 Klickitat St.:'Iceland' , ':')
     with the result being
          ['Bill Jones', '2424 Klickitat St.', 'Iceland']
   * String creation by placing a string separator between the string items of a
     tuple or list. For example, to create the colon-separated string above
     from the list above we would issue the following command:
          string.join(['Bill Jones', '2424 Klickitat St.', 'Iceland'], ':')
   * Removal of whitespace. Given the string `'   a b    '' the Python
     command
          string.strip('     a b     ')
     would result in the string `'a b''
   * Substring search. Given the string `'ahelluvashow'' the Python
     command
          string.index('ahelluvashow' , 'luva')
     would return the integer 4
   * Right, left, and center justification of strings. For example, we can
     take the following strings: 'horse', 'mule' , 'ox' , 'guido' and by
     repeatedly applying string.rjust(s, 10) where s is each of the above
     strings we can get the following output:
               horse
                mule
                  ox
               guido

stdwin
------

Using the stdwin module, the Python (and C) programmer can create
source code with graphic windowing which will run on all of the
following platforms:

   * X-Windows
   * Macintosh using Think C 4.0
   * Alphanumeric Terminals
   * MS-DOS with a dumb display using Microsoft C
   * Atari ST using MWC or Turbo C

Of course no window system's potential is maximized under stdwin, but
this is offset by the portability advantage.

A brief vignette of methods in the stdwin module:

   * event polling
   * scrollbars
   * color fetching
   * semi-automatic menu widget creation
   * cut buffers
   * point, line, box drawing routines
   * text widgets

unix
----

There is a BSD 4.3 socket interface. There is a posix module that
provides access to to operating system functionality that is
standardised by the C Standard and the POSIX standard. For example, one
automatically gets a dictionary of environmental variables. It allows
for changing the current working directory, forking, directory listing,
obtaining the current and parent process id and so forth. Another module
named `posixpath' allows one to easily perform file
naming and testing (ie, basename of a directory path, intelligently
join two directory paths, filename or directory tests).

Common Questions
****************

   * How do you print something without having a carriage return appended to
     it?

     You end your print statement with a comma. For example,
          i = 5
          print 'i = ',
          print i
     will result in:
     `i = 5'
     as output.
   * Do I have to leave the interpreter each time I want a modules source
     code re-evaluated?

     No. If your module name is shc.py and you have loaded it into the
     `Python' interpreter. Type the following exactly: `reload(shc)'

   * What are these numbers that show up after I do certain statements?

     The Python interpreter prints the value of an expression statement
     unless it is none -- this is done so you can use the interpreter as an
     interactive calculator. The simplest way of avoiding the printing of the
     value is to assign it to a dummy value.

   * If I am looking for the string "\section{Loving Make}" why doesnt the
     following regexp work: `sect_regex = '\\section{\(.*\)} .*''

     To include a literal backslash in a regexp you must double it, but to
     include one in a Python string literal you must QUADRUPLE it. So the
     correct regexp is: `sect_regex = '\\\\section{.*}.*''

     But the `\(' and `\)' worked fine!

     As stated in the reference manual under "String Literals," a backslash
     that is followed by a character that is not one of the Standard C escape
     sequences such as `\n' or `\t' stays in the string. As far as
     I know the only character that has a special meaning following a
     backslash in regular expressions as well as a Python string literal is
     the backslash.

   * Ok, I am in the interpreter and I want to run a Python script and pass
     it command line arguments. Can I do it?

     Sure. Two methods:

       1.      import sys
               sys.argv = [ '-c' , 'red' ]
               execfile('colormap')
       2.      import os
               os.system('colormap -c red')


Advanced Questions
******************


  1. From [e-mail]:
     How can I best to put a Python interpreter into, say, 12
     processes given that each interpreter needed to interface to process
     specific not just general library code and I don't
     want the overhead of the core Python code in every process
     given that I'd mananged to produce a shared library version of it on
     my SUN

     Answer:
     It sounds like your problem is that you want to use a shared library
     for most of the code of the Python interpreter, but you want each
     interpreter to have different extensions, and you don't want to have
     to build 12 different shared libraries (which would undo most of the
     benefit of shared libraries).

     Assuming you aren't using threads (all processes sharing the same
     address space for data), it should be possible to do this using only a
     tiny change in the code: move the initialized array of module init
     functions (inittab in "config.c") out of the shared library into the
     main programs, and initialize it differently in each program.  Or
     allocate some extra slots in it and dynamically add extra entries
     before initializing the interpreter.  The table is searched each time
     a module isn't found, so you may even add entries even dynamically --
     Python postpones the search for and the call to a module's init
     function until the first time it is imported.

     Alternatively, you could use dynamic loading (read misc/DYNLOAD in the
     distribution), but this would probably be slow and seems unnecessary.

          --Guido van Rossum, CWI, Amsterdam <[e-mail]>
          "That was never five minutes just now!"
          "I'm afraid it was."

Additional Information
**********************

There are two python modes for emacs:

   * A standard one packed with the Python distribution (in
     $DISTRIB/misc/python-mode.el where DISTRIB==the top level of where
     Python was untarred to) that works with the
     shell mode that is still common in Emacs.
   * An experimental mode by Terrence Brannon that works with comint (which along with
     cmushell will replace the current shell-mode in Emacs 19) and allows one
     to have a startup file named `.python' in which you can
     automatically load in often-used modules. It also robustly facilitates
     interprocess communication between Emacs and Python -- simple types as
     well as lists may be passed freely between Emacs and Python. Other types
     such as Python's dictionaries and Emacs' vectors and association and
     property lists do not have converter routines yet written.


Obtaining
*********

Anonymous FTP to ftp.cwi.nl (IP address 192.16.184.180) in /pub filename
`python*.tar.Z' where * stands for a version number. This is a
compressed UNIX tar file containing the C source and LaTeX documentation
for the Python interpreter. It includes the Python library modules and
the `Stubcode' interpreter as well as many example Python programs.
Total disk space occupied by the distribution is about 3 megabytes;
compilation requires 1-3 megabytes depending on the configuration built,
the compile options, and so forth.


Terrence Brannon       ([e-mail])
medical biology via acupuncture and particle physics













Received: from uvaarpa.Virginia.EDU by charon.cwi.nl with SMTP
    id AA02292 (5.65b/2.10/CWI-Amsterdam); Thu, 13 Aug 1992 21:04:10 +0200
Received: from server.cs.virginia.edu by uvaarpa.Virginia.EDU id aa00458;
          13 Aug 92 15:00 EDT
Received: from banyan.cs.Virginia.EDU by uvacs.cs.Virginia.EDU (4.1/5.1.UVA)
    id AA11195; Thu, 13 Aug 92 15:00:17 EDT
Posted-Date: Thu, 13 Aug 92 15:00:12 EDT
Return-Path: <[e-mail]>
Received: by banyan.cs.Virginia.EDU (4.1/SMI-2.0)
    id AA17410; Thu, 13 Aug 92 15:00:12 EDT
Date: Thu, 13 Aug 92 15:00:12 EDT
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Question about Macintosh python

Has anyone bothered to implement sockets for the Mac version of
Python?

Thanks,

Steve










Replied: Sun, 16 Aug 1992 20:31:21 +0200
Replied: [e-mail]
Received: from uunet.ca by charon.cwi.nl with SMTP
    id AA22864 (5.65b/2.10/CWI-Amsterdam); Sun, 16 Aug 1992 17:06:04 +0200
Received: from tslwat by mail.uunet.ca with UUCP id <9781>; Sun, 16 Aug 1992 11:05:57 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Sun, 16 Aug 92 11:10 EDT
Message-Id: <[e-mail]>
Date:     Sun, 16 Aug 1992 11:10:00 -0400
From: [e-mail] (Lou Kates)
To: [e-mail]
Subject: splitfields


string.splitfields('abc','') appears to go into an endless loop.  I would
have thought that it would return ['a','b','c'].

Lou Kates, [e-mail]










Replied: Mon, 17 Aug 1992 10:35:09 +0200
Replied: "[e-mail] (Lou Kates) "
Received: from uunet.ca by charon.cwi.nl with SMTP
    id AA08100 (5.65b/2.10/CWI-Amsterdam); Mon, 17 Aug 1992 02:49:09 +0200
Received: from tslwat by mail.uunet.ca with UUCP id <10155>; Sun, 16 Aug 1992 20:48:48 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Sun, 16 Aug 92 20:44 EDT
Message-Id: <[e-mail]>
From: [e-mail] (Lou Kates)
Subject: Re: splitfields (fwd)
To: [e-mail]
Date:     Sun, 16 Aug 1992 20:44:56 -0400
X-Mailer: ELM [version 2.3 PL11]

>
> >string.splitfields('abc','') appears to go into an endless loop.  I would
> >have thought that it would return ['a','b','c'].
>
> What makes you think so?  I believe a reasonable mathematical
> definition of splitfields(x, y) would return an infinite list if y==''.
>

The following seem to be reasonable properties for splitfields to
have for all strings s and t:

    1. joinfields(splitfields(s, t), t) == s
    2. splitfields(joinfields(s, t), t) == s
    3. splitfields(s, t) finite

That is,  for identical separators,  t, splitfields commutes with
joinfields and is finite for finite s. In other words, joinfields
and splitfields  are  inverses of  each other and splitfields  is
finite for finite s.

Note that

    joinfields(['abc'],'')
    joinfields(['a','b','c'],'')
    joinfields(['ab','c'],'')
    joinfields(['a','bc'],'')
    joinfields(['','abc'],'')
    etc.

are all the same so that splitfields  is not 1-to-1 and so has no
inverse (which is what properties #1 and #2 imply).

I suppose  that going  into an   endless loop could represent the
fact  that   there  is no  unique  inverse to  any of the  above;
however, I think it  would  be more  useful to pick  one of  them
(this might correspond to picking the  generalized  inverse  of a
matrix which  is  a   similar  situation)   or else  generate  an
exception.

If we were to pick one of them

    splitfields('abc','') == ['a','b','c']

seems generally the most useful since we already have an easy way
of converting  'abc' to ['abc'] simply  by enclosing it in square
brackets.

--
Lou Kates, [e-mail]










Received: from uunet.ca by charon.cwi.nl with SMTP
    id AA11657 (5.65b/2.10/CWI-Amsterdam); Wed, 19 Aug 1992 20:19:03 +0200
Received: from tslwat by mail.uunet.ca with UUCP id <10624>; Wed, 19 Aug 1992 14:17:40 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Wed, 19 Aug 92 13:35 EDT
Message-Id: <[e-mail]>
From: [e-mail] (Lou Kates)
Subject: Re: more on splitfields
To: [e-mail]
Date:     Wed, 19 Aug 1992 13:35:34 -0400
X-Mailer: ELM [version 2.3 PL11]

> >
> >    a = string.splitfields(s, sep)
> >
> I currently think that the best thing to do is to raise an exception
> when sep is ''.  First, any one of the possible results are easy to
> get with other means.  Since almost all calls will specify a literal
> as separator argument, I doubt that people will want to use
> splitfields() for what they can express easier.  Second, there is an

Actually the way this entire thing  came about what that I wanted
to derive a list of single characters from a string. Of course, I
could write a simple loop but thought that perhaps there might be
an easier  way  using some library function/method. Is there such
an easier way?

> anomaly for splitfields('',''): in to your previous proposal it should
> return [], but joinfields([], sep ) is ill-defined: the list must have
> at least one element!  So an exception seems to be the best solution.
>

OK. I agree with you.

While  we    are  on  the  topic   of infinite  loops in  library
functions/methods the following will also cause infinite looping:

    a = [2, 'abc']
    a.append(a)

There are a number of possibilities:

    1.   let it loop infinitely as it does now

    2.   allow circularity

    3.   regard this to be the same as:

        a.append(deepcopy(a))

         in which   case  there is   no circularity. In  this
         example we would get:

        [2, 'abc', [2, 'abc']]

    4.   detect circularity and raise an exception

I suppose  that there are  significant implementation issues here
as well as desirability ones.

Lou Kates, [e-mail]











Received: from hopscotch.ksr.com by charon.cwi.nl with SMTP
    id AA01317 (5.65b/2.10/CWI-Amsterdam); Wed, 19 Aug 1992 23:31:14 +0200
Received: from ksr.com (frankenstein.ksr.com) by hopscotch.ksr.com with SMTP
    id AA23347; Wed, 19 Aug 1992 17:29:45 -0400
Received: from kaos.ksr.com by ksr.com (4.0/SMI-3.2)
    id AA12323; Wed, 19 Aug 92 17:30:39 EDT
Received: by kaos.ksr.com (4.0/KSR-2.0)
    id AA08898; Wed, 19 Aug 92 17:30:38 EDT
Message-Id: <[e-mail]>
To: [e-mail] (Lou Kates)
Subject: Self-referential objects (was Re: more on splitfields)
Cc: [e-mail]
Date: Wed, 19 Aug 92 17:30:36 -0400
From: Tim Peters <[e-mail]>

>  ...
>  While  we    are  on  the  topic   of infinite  loops in  library
>  functions/methods the following will also cause infinite looping:
>
>      a = [2, 'abc']
>      a.append(a)
>
>  There are a number of possibilities:
>  ...

Works fine for me, Lou:

Python 0.9.6 (>= 1 Jan 1992).
Copyright 1990, 1991, 1992 Stichting Mathematisch Centrum, Amsterdam
>>> a = [2,'abc']
>>> a.append(a)
>>> len(a)
3
>>> (a is a[2])
1
>>>

This is a UNIX(tm) flavor of Python.  Suspect you're looking at an
installation problem, or are trying to print the thing (& the docs warn
against trying to print self-referential objects -- you do get into an
infinite loop then).

personally-already-like-what-python-does-with-this-ly y'rs  - tim

Tim Peters   Kendall Square Research Corp
[e-mail],         ksr![e-mail]










Replied: Thu, 20 Aug 1992 10:19:05 +0200
Replied: "[e-mail] (Lou Kates) "
Received: from uunet.ca by charon.cwi.nl with SMTP
    id AA17053 (5.65b/2.10/CWI-Amsterdam); Thu, 20 Aug 1992 06:03:30 +0200
Received: from tslwat by mail.uunet.ca with UUCP id <10743>; Thu, 20 Aug 1992 00:03:19 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Thu, 20 Aug 92 00:07 EDT
Message-Id: <[e-mail]>
From: [e-mail] (Lou Kates)
Subject: Re: Self-referential objects (was Re: more on splitfields)
To: [e-mail] (Tim Peters)
Date:     Thu, 20 Aug 1992 00:07:01 -0400
Cc: [e-mail]
In-Reply-To: <[e-mail]>; from "Tim Peters" at Aug 19, 92 5:30 pm
X-Mailer: ELM [version 2.3 PL11]

>
> >  ...
> >  While  we    are  on  the  topic   of infinite  loops in  library
> >  functions/methods the following will also cause infinite looping:
> >
> >      a = [2, 'abc']
> >      a.append(a)
> >
>
> Works fine for me, Lou:
>
> Python 0.9.6 (>= 1 Jan 1992).
> Copyright 1990, 1991, 1992 Stichting Mathematisch Centrum, Amsterdam
> >>> a = [2,'abc']
> >>> a.append(a)

The version of Python that I have is 0.9.1.  Evidently there is a difference
between the two versions.

Lou Kates, [e-mail]










Replied: Mon, 31 Aug 1992 10:56:35 +0200
Replied: "[e-mail] (Jon Vander Hill) [e-mail]"
Received: from meermin.cwi.nl by charon.cwi.nl with SMTP
    id AA19418 (5.65b/2.10/CWI-Amsterdam); Fri, 28 Aug 1992 21:40:03 +0200
Received: from srv01s4.cas.org by meermin.cwi.nl with SMTP
    id AA14012 (5.65a/2.10/CWI-Amsterdam); Fri, 28 Aug 1992 19:40:00 GMT
Date: Fri, 28 Aug 92 15:37:32 EDT
From: [e-mail] (Jon Vander Hill)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: miniedit.py


I'm trying to get miniedit.py to run.
My system particulars are as follows:

SunOS 4.1.2
OpenWindows 3.0
Python 0.9.7beta
Stdwin 0.9.7 (X11 port)

I'm trying to run the application directly from a shell (via the #!
mechanism).  The application puts up its window, but doesn't load the
file given on the command line and does not seem to respond to input
events.  I'm able to kill it by generating a SIGINT in the shell I
start it from and move the mouse cursor into the application window.

If it helps, the microedit.py application comes up, loads the file,
and responds to input events, so I'm thinking the problem
is in the miniedit application itself or possibly the python stdwin library.

I'm pretty new to python, so keep any advice in the simplest terms.

Jon Vander Hill
[e-mail]










Forwarded: Fri, 04 Sep 1992 14:09:59 +0200
Forwarded: "jack "
Forwarded: Wed, 02 Sep 1992 10:17:11 +0200
Forwarded: "jack "
Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA17845 (5.65b/2.10/CWI-Amsterdam); Mon, 31 Aug 1992 10:56:37 +0200
Received: by voorn.cwi.nl with SMTP; Mon, 31 Aug 1992 08:56:36 GMT
Message-Id: <[e-mail]>
To: [e-mail] (Jon Vander Hill)
Cc: [e-mail]
Subject: Re: miniedit.py
In-Reply-To: Your message of "Fri, 28 Aug 1992 15:37:32 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 31 Aug 1992 10:56:35 +0200
Sender: [e-mail]

>I'm trying to get miniedit.py to run.
>My system particulars are as follows:
>
>SunOS 4.1.2
>OpenWindows 3.0
>Python 0.9.7beta
>Stdwin 0.9.7 (X11 port)
>
>I'm trying to run the application directly from a shell (via the #!
>mechanism).  The application puts up its window, but doesn't load the
>file given on the command line and does not seem to respond to input
>events.  I'm able to kill it by generating a SIGINT in the shell I
>start it from and move the mouse cursor into the application window.

I'm sorry: there's a bug in 0.9.7beta version (that's why it's a
beta version!), which make it think that certain objects are "false"
when they should actually be considered "true".

There have been several releases labeled "0.9.7beta", and I'm not sure
the current version still has the bug in it -- there's another bug I
need to hunt down before I dare to make a new beta release.  Anyway,
here's a description of a fix.  Edit the file "ceval.c" and find the
definition of function testbool().  There is a sequence of code ending
like this:

    else if (v->ob_type->tp_as_sequence != NULL)
        res = (*v->ob_type->tp_as_sequence->sq_length)(v);
    else
        res = 0;

The 0 in the last line should be a 1.  That's all there is to the fix!

Happy hacking...

(BTW, I'm extremely glad that you listed your environment so carefully
-- without it I would have had a hard time this was for real.)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I'm sorry, is this a five-minute argument, or the full half-hour?"










Replied: Wed, 02 Sep 1992 21:43:25 +0200
Replied: [e-mail] (Jon Vander Hill)
Replied: [e-mail]
Received: from srv01s4.cas.org by charon.cwi.nl with SMTP
    id AA16927 (5.65b/2.10/CWI-Amsterdam); Wed, 2 Sep 1992 20:07:26 +0200
Date: Wed, 2 Sep 92 14:07:09 EDT
From: [e-mail] (Jon Vander Hill)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: difficulty with microedit.py on a Mac
Cc: [e-mail]

Environment:

Mac Plus, 4Mb
System 6.0.5
Finder 6.1.5
Python 0.9.7 (from ftp.cwi.nl)

I placed microedit.py in the same folder as python.
I needed stdwinevents.py in order to import microedit.py.

I brought up python and ran the following commands:

import sys
sys.argv = ['','microedit.py']
import microedit

A window was created entitles "microedit.py".
The following message appeared on the title bar:
   zrealloc(0x2ec2a8,0): out of mem
I hit the return key.
The message "press <<return>> to exit" appeared on
the title bar of the python console.

Any help would be appreciated.

Also, is there any doc that describes what modules
are compiled into Python 0.9.7 for the Mac?

Jon Vander Hill, System Engineer              Chemical Abstracts Service
internet: [e-mail] (preferred)             P.O. Box 3012 (preferred)
          [e-mail]                      2540 Olentangy River Road
uucp:     uunet!osu-cis!chemabs!jon           Columbus, Ohio 43210
bitnet:   jon@CAS                             USA
phone:    [phone]











To: [e-mail] (Jon Vander Hill)
cc: [e-mail]
Subject: Re: difficulty with microedit.py on a Mac
In-reply-to: Your message of "Wed, 02 Sep 1992 14:07:09 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Wed, 02 Sep 1992 21:43:24 +0200
Sender: guido

>Python 0.9.7 (from ftp.cwi.nl)
>The following message appeared on the title bar:
>   zrealloc(0x2ec2a8,0): out of mem

I'm sorry, the 0.9.7beta Mac Python binary for a while contained the
same bug as the sources there, as explained in a previous message to
this list.  I have placed a fixed Mac Python there around 30 August,
so if you fetched it before that date you should fetch a fresh copy
and try again.  (Note that the new file isn't compacted with stuffit.
I could fix it but I only occasionally have access to a Mac where I
can compile Python these days...)

>Also, is there any doc that describes what modules
>are compiled into Python 0.9.7 for the Mac?

Not really -- there probably should be...  Here's an excerpt from the
config file I used:

#define STDWIN 1
[...]
    /* Standard modules */
    {"time",    inittime},
    {"math",    initmath},
    {"regex",    initregex},

    /* Mac-specific modules */
    {"mac",        initmac},
#ifdef USE_STDWIN
    {"stdwin",    initstdwin},
#endif
    {"marshal",    initmarshal},

Note that the modules 'sys' and 'builtin' as well as '__main__' are
always present (see the Library reference manual for a description of
these).

BTW, for documented modules it is of course trivial to test whether
they exist or not:

    try:
        import foo
        print 'foo exists'
    except ImportError:
        print 'foo does not exist'

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"The lawnmower.  Surely such a gadget could not have been generated
independently in two separate areas."










Received: from newton.ncsa.uiuc.edu by charon.cwi.nl with SMTP
    id AA18565 (5.65b/2.10/CWI-Amsterdam); Wed, 2 Sep 1992 22:04:05 +0200
Received: from void.ncsa.uiuc.edu by newton.ncsa.uiuc.edu with SMTP id AA20905
  (5.65a/IDA-1.4.2 for [e-mail]); Wed, 2 Sep 92 15:04:02 -0500
Return-Path: <[e-mail]>
Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1)
    id AA24485; Wed, 2 Sep 92 15:02:40 CDT
Date: Wed, 2 Sep 92 15:02:40 CDT
From: [e-mail] (Daniel LaLiberte)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: difficulty with microedit.py on a Mac

If anyone wants to do GL like things on the mac, my previous work
on python should still apply, though it needs to be updated to
use VOGL instead of our NGL which we have dropped.  Just forward
requests to me.

dan










Replied: Tue, 08 Sep 1992 10:34:15 +0200
Replied: "[e-mail] (Lou Kates) "
Received: from uunet.ca by charon.cwi.nl with SMTP
    id AA06609 (5.65b/2.10/CWI-Amsterdam); Tue, 8 Sep 1992 06:04:05 +0200
Received: from tsltor by mail.uunet.ca with UUCP id <10356>; Mon, 7 Sep 1992 23:42:06 -0400
Received: from tslwat by falcon.teleride.on.ca with uucp
    (Smail3.1.26.7 #5) id m0mRw7U-0000dpC; Mon, 7 Sep 92 23:20 EDT
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Mon, 7 Sep 92 23:02 EDT
Message-Id: <[e-mail]>
From: [e-mail] (Lou Kates)
Subject: Python vs. awk
To: [e-mail]
Date:     Mon, 7 Sep 1992 23:02:44 -0400
X-Mailer: ELM [version 2.3 PL11]



The following  compares a  Python program   to one written in awk
(actually nawk).  I realize that Guido feels  that Python  should
not really be compared to awk or perl since its aims are somewhat
different but I still feel that this sort of exercise is useful.

The two programs below exchange two fields preserving whitespace.
These fields  can  be optionally   specified on the command  line
using the   easiest  way that  the two  languages support (getopt
library for Python and the x=12 form for awk). The Python program
is 27  lines compared  to  12 statements and 10 lines for the awk
program.

The following is the breakdown:

                Python        Awk
Declaration statements        1 stmt        0 stmts
Option processing        5 stmts        1 stmts
Argument processing        2 stmts        0 stmts
Reading & looping over input    3 stmts        0 stmts
Field splitting            1 stmt        0 stmts
Get list of whitespace fields    9 stmts     3 stmts
Check number of fields        1 stmt        1 stmt
Loop to swap & print fields    5 stmts        6 stmts (4 lines)
End of block stmts        0 stmts        1 stmt

Total                27 stmt        12 stmts (10 lines)


The areas of saving for awk are:

1.   Awk saves 9 lines by implicitly processing the command line,
     including options and arguments and reading and looping over
     the input as well as doing field splitting.

2.   Awk's gsub   allows  one to   compactly obtain  the list  of
     whitespace. In Python you have to do it by hand.

3.   With Python you have to build up  the output in a buffer and
     in awk you can use printf to avoid this.

My conclusions are that Python needs some additions to the library
to:

1.   facilitate command processing, option processing and looping
     over input. An expanded version of the implicit loop program
     that was posted a while ago to this list could help here.

2.   perform sub  and  gsub functions.   These could return a new
     string with   the replacement  done  since Python's  strings
     cannot be changed in place (immutable).

3.   provide a way of printing out  a partial line without having
     a space placed  at the end of it to reduce the need to build
     up print buffers in the program.


=== awk program ===


BEGIN { if (x == 0) x = 1; if (y == 0) y = 2 }
NF >= x && NF >=y {
    line = $0;
    gsub(/[^ \t]+/, ":", line);
    split(line, s, ":");
    t = $y; $y = $x; $x = t;
    for(i=1; i<=NF; i++)
        printf("%s%s", s[i], $i);
    print "";
}


=== Python program ===

import getopt, regexp, string, sys
pat = regexp.compile('[^ \t]+')
options, files = getopt.getopt(sys.argv[1:], 'x:y:')
x, y = 1, 2
for t in options:
    if 'x' in t[0]: x = string.atoi(t[1])
    if 'y' in t[0]: y = string.atoi(t[1])
fp = sys.stdin
if files: fp = sys.open(files[0])
while 1:
    line = fp.readline()
    if not line: break
    fl = string.split(line)
    wl, line = [], line[:-1]
    while 1:
        t = pat.exec(line)
        if t:
            wl.append( line[ :t[0][0] ])
            line = line[ t[0][1]: ]
        else:
            break
    if len(fl) > x and len(fl) > y:
        fl[x], fl[y] = fl[y], fl[x]
        buf = ''
        for i in range(0, len(fl)):
            buf = buf + wl[i] + fl[i]
        print buf
--
Lou Kates, [e-mail]










Received: from uunet.ca by charon.cwi.nl with SMTP
    id AA25374 (5.65b/2.10/CWI-Amsterdam); Mon, 14 Sep 1992 20:28:08 +0200
Received: from tslwat by mail.uunet.ca with UUCP id <9818>; Mon, 14 Sep 1992 14:27:54 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Sun, 13 Sep 92 19:02 EDT
Message-Id: <[e-mail]>
Date:     Sun, 13 Sep 1992 19:02:00 -0400
From: [e-mail] (Lou Kates)
To: [e-mail]
Subject: more on awk vs. python example




This is  a  reworked Python   vs. awk (actually nawk)  comparison
using the  improvement  suggested by Guido. (Note that  I have an
older  version  of  Python  and  the exec function in the program
below is now apparently  called match in more recent versions  of
Python). The Python program is now  only 50% larger  than the awk
program and the part that does the real work is actually smaller.

The size   advantage  of awk   comes entirely from its  automatic
option processing, argument processing, input loop processing and
field splitting. The Python algorithm actually beats  the awk one
in the portion that does the real work.

The following is the breakdown:

                Python        Awk
Declaration statements        1 stmt        0 stmts
Default options            1 stmt          1 stmt
Option processing        3 stmts        0 stmts
Argument processing        3 stmts        0 stmts
Reading & looping over input    3 stmts        0 stmts
Field splitting            1 stmt        0 stmts

Get list of whitespace fields    0 stmts     3 stmts
Check number of fields        1 stmt        1 stmt
Swap & print fields            6 stmts        6 stmts (4 lines)
End of block stmts        0 stmts        1 stmt

Total                18 stmt        12 stmts (10 lines)

Also to  be mentioned is that  the the Python approach eliminates
the loop  over  the  arguments which  is nice  (although it  does
require  an  explicit  loop  over  the input lines which awk does
not).

On the other hand, the line:

    line = line[:a] + line[c:d] + line[b:c] + line[a:b] + line[d:]

in the Python  program is a bit  difficult to follow and what one
really wants to  say  (to be closer  to how you might think  when
developing pseudocode) is:

    swap line[a:b] and line[c:d]

        or

    line[a:b], line[c:d] = line[c:d], line[a:b]

but one can't because strings are immutable.

Extrapolating the  advantages  listed for   awk, we see that  the
savings as  a percentage of code size would tend to be relatively
smaller for  larger  programs. It  is likely that  past a certain
size  Python has smaller code size while under a certain size awk
does.

There really  is no  reason that   with flags to allow  automated
processing   of    arguments,   automatic processing  of options,
automatic processing of  the input  loop  and    automatic  field
splitting plus mutuable strings that the Python code could not be
made to beat the awk code even for programs of this size.

It would also  be  nice and certainly  could not hurt to have the
sub and gsub functions of awk in the Python string library.


=== awk program ===

BEGIN { if (x == 0) x = 1; if (y == 0) y = 2 }
NF >= x && NF >=y {
    line = $0;
    gsub(/[^ \t]+/, ":", line);
    split(line, s, ":");
    t = $y; $y = $x; $x = t;
    for(i=1; i<=NF; i++)
        printf("%s%s", s[i], $i);
    print "";
}


=== Python program ===

import getopt, regexp, string, sys
options, files = getopt.getopt(sys.argv[1:], 'x:y:')
x, y = 1, 2
for (a, b) in options:
    if 'x' in a: x = string.atoi(b)
    if 'y' in a: y = string.atoi(b)
if x > y: x, y = y, x
fp = sys.stdin
if files: fp = open(files[0], 'r')
while 1:
    line = fp.readline()
    if not line: break
    if len(string.split(line)) >= y:
        t = (regexp.compile('[ \t]*([^ \t]+)' * y)).exec(line)
        (a, b), (c, d) = t[x], t[y]
        line = line[:a] + line[c:d] + line[b:c] + line[a:b] + line[d:]
        print line[:-1]










Received: from uunet.ca by charon.cwi.nl with SMTP
    id AA05779 (5.65b/2.10/CWI-Amsterdam); Sun, 20 Sep 1992 21:41:21 +0200
Received: by mail.uunet.ca via suspension id <10419>; Sun, 20 Sep 1992 15:11:36 -0400
Received: from tslwat by mail.uunet.ca with UUCP id <11870>; Sat, 19 Sep 1992 21:49:43 -0400
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Sat, 19 Sep 92 21:44 EDT
Message-Id: <[e-mail]>
From: [e-mail] (Lou Kates)
Subject: Python OO Examples
To: [e-mail]
Date:     Sat, 19 Sep 1992 21:44:29 -0400
X-Mailer: ELM [version 2.3 PL11]

Does anyone have any good examples of object oriented programming in
Python?  (I already have the Python library, of course.)

--
Lou Kates, [e-mail]










Replied: Tue, 29 Sep 1992 21:37:39 +0100
Replied: Python Mailing List <[e-mail]>
Received: from gateway.sequent.com by charon.cwi.nl with SMTP
    id AA07314 (5.65b/2.10/CWI-Amsterdam); Tue, 29 Sep 1992 20:33:06 +0100
Received: from eng2.sequent.com by gateway.sequent.com (5.61/1.34)
    id AA23808; Tue, 29 Sep 92 12:32:09 -0700
Received: by eng2.sequent.com (5.65/1.34)
    id AA14602; Tue, 29 Sep 92 12:32:48 -0700
Message-Id: <[e-mail]>
To: Python Mailing List <[e-mail]>
Subject: Why doesn't python die gracefully on an SIGTERM???
Priority: Normal
Precedence: first-class
Organization: Sequent Computer Systems, Inc.
          Decision Support Group - MailStop: RHE2-358
          15450 S.W. Koll Parkway
          Beaverton, OR  97006
X-Phone: [phone]
X-Fax: [phone]
X-Uucp: ...!uunet!sequent!jaap
X-Internet: [e-mail]
X-Face: C4Cnai$>Eja5I6Vq?(gdN#SXX#`-XgAnmUn&e54sx7@1>q@vkrd_XnH![P>w.:7IJJ;{Bts
 WJd)u&G!V}0OR?2o5cUgIY}.T{g]PMC=*~]3n_t)S-ZkC(WG}3:#hcA6Oazx:}yc&k,hsF7D},7x>l
 nyfRjO7$@]fHBN>aC9-M3pKfbYHiy!PWD{_bx~fo})b4tU.;Ao%x[upCI,
Date: Tue, 29 Sep 92 12:32:47 PDT
From: Jaap Vermeulen <[e-mail]>


I wrote some python programs that temporarily modify data outside the
process (in this case utmp). Normally, that data will be restored to the
correct state when the program terminates normally or when I interrupt
the execution of the program (python does a good job of cleaning up).

However, often I run such a python program in the background. Now the
program ignores the SIGINT and any other signal will cause a non-graceful
termination where python does not clean up at all.

Would it be possible to add at least some functionality to allow for
graceful termination after the most common signal, SIGTERM?

Or are there any other plans in this area?

Thanks,

    -Jaap-
--
Jaap Vermeulen                    +--------------------------+
                        | Sequent Computer Systems |
    Internet : [e-mail]        | Beaverton, Oregon       |
    Uucp     : ...uunet!sequent!jaap    +--------------------------+










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA07821 (5.65b/2.10/CWI-Amsterdam); Tue, 29 Sep 1992 21:37:38 +0100
Received: by voorn.cwi.nl with SMTP; Tue, 29 Sep 1992 20:37:37 GMT
Message-Id: <[e-mail]>
To: Python Mailing List <[e-mail]>
Subject: Re: Why doesn't python die gracefully on an SIGTERM???
In-Reply-To: Your message of "Tue, 29 Sep 1992 12:32:47 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 29 Sep 1992 21:37:36 +0100
Sender: [e-mail]

>Would it be possible to add at least some functionality to allow for
>graceful termination after the most common signal, SIGTERM?

This must be one of the most frequently requested features: either
provide a general signal handling mechanism, or provide at least a way
to clean up when a signal arrives.  So far I've avoided the issue of
designing a "safe" signal handling mechanism for Python, because it's
almost impossible to do right for everybody without adding
considerable overhead to the interpreter.   Many proposed solutions
don't work because of the interpreter's structure (e.g., anything
involving longjmp() back to the main loop is unsafe because it may
leave large amounts of allocated memory unreachable and leave internal
data structures in an inconsistent state).  But given the persistence
of those who ask for some kind of signal handling, I suppose I simply
have to add *something*.

First, in 0.9.7 there will be a cleanup feature that's independent of
try...finally: if you assign a function object to sys.exitfunc, it
will be called when Python is about to exit.  I suppose it shouldn't
be too hard to arrange that this is called when SIGTERM (or SIGHUP)
arrives too.

There will be a risk when using this feature: some part of the library
or interpreter may be busy when the signal arrives and not allow
re-entrance.  A famous example in C is trying to use printf() to print
a message from a signal handler: this may fail (causing a core dump)
when the signal arrives while the mainline code of the program is
already using printf().  Since Python uses C's stdio for its own I/O,
this may occur in Python as well.  Other risks specific to Python are
touching mutable global data structures such as lists, which may be
inconsistent when an update is in progress.  But again a careful
Python programmer can minimize the risk by restricting the clean-up
procedure to the absolutely minimum necessary.

Another idea, harder to implement, but also more generally useful, is
to add an interface whereby arbitrary signals can be mapped to
exceptions just like SIGINT is already mapped to KeyboardInterrupt.
Or perhaps they should be mappable to function calls (and the default
mapping for SIGINT could be a function that raises KeyboardInterrupt).
In this case, the actual call to the (Python) handler will be delayed
slightly so the interpreter can make sure there are no inconsistent
(internal) data structures to worry about.  This is already done for
SIGINT: the actual SIGINT handler just sets a global flag, which is
checked every few "virtual instructions".

There is a problem with blocking system calls like read() that needs
to be fixed in a more general way, too, if this solution is adopted:
some UNIX systems restart system calls that are interrupted by a
signal handler.  This would mean that the Python handler would be
called only after the call returns, which may be never (e.g. when
reading from a socket or tty).  The current solution, adopted for a
few important blocking calls only (sleep, read), is to temporarily
change the SIGINT handler to one that calls longjmp() to a safe point
in the Python wrapper.  This has to be extended to all caught signals
and all (or at least most) blocking calls, else the signal mechanism
would not be reliable.  I'll have to think about this long and deep
before I proceed to implement it...

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I think you have not fully appreciated our attitude towards the tenants"










To: Python Mailing List <[e-mail]>
Subject: Re: Why doesn't python die gracefully on an SIGTERM???
In-reply-to: Your message of "Tue, 29 Sep 1992 12:32:47 MDT."
             <[e-mail]>
From: Guido van Rossum <[e-mail]>
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 29 Sep 1992 21:37:36 +0100
Sender: guido

>Would it be possible to add at least some functionality to allow for
>graceful termination after the most common signal, SIGTERM?

This must be one of the most frequently requested features: either
provide a general signal handling mechanism, or provide at least a way
to clean up when a signal arrives.  So far I've avoided the issue of
designing a "safe" signal handling mechanism for Python, because it's
almost impossible to do right for everybody without adding
considerable overhead to the interpreter.   Many proposed solutions
don't work because of the interpreter's structure (e.g., anything
involving longjmp() back to the main loop is unsafe because it may
leave large amounts of allocated memory unreachable and leave internal
data structures in an inconsistent state).  But given the persistence
of those who ask for some kind of signal handling, I suppose I simply
have to add *something*.

First, in 0.9.7 there will be a cleanup feature that's independent of
try...finally: if you assign a function object to sys.exitfunc, it
will be called when Python is about to exit.  I suppose it shouldn't
be too hard to arrange that this is called when SIGTERM (or SIGHUP)
arrives too.

There will be a risk when using this feature: some part of the library
or interpreter may be busy when the signal arrives and not allow
re-entrance.  A famous example in C is trying to use printf() to print
a message from a signal handler: this may fail (causing a core dump)
when the signal arrives while the mainline code of the program is
already using printf().  Since Python uses C's stdio for its own I/O,
this may occur in Python as well.  Other risks specific to Python are
touching mutable global data structures such as lists, which may be
inconsistent when an update is in progress.  But again a careful
Python programmer can minimize the risk by restricting the clean-up
procedure to the absolutely minimum necessary.

Another idea, harder to implement, but also more generally useful, is
to add an interface whereby arbitrary signals can be mapped to
exceptions just like SIGINT is already mapped to KeyboardInterrupt.
Or perhaps they should be mappable to function calls (and the default
mapping for SIGINT could be a function that raises KeyboardInterrupt).
In this case, the actual call to the (Python) handler will be delayed
slightly so the interpreter can make sure there are no inconsistent
(internal) data structures to worry about.  This is already done for
SIGINT: the actual SIGINT handler just sets a global flag, which is
checked every few "virtual instructions".

There is a problem with blocking system calls like read() that needs
to be fixed in a more general way, too, if this solution is adopted:
some UNIX systems restart system calls that are interrupted by a
signal handler.  This would mean that the Python handler would be
called only after the call returns, which may be never (e.g. when
reading from a socket or tty).  The current solution, adopted for a
few important blocking calls only (sleep, read), is to temporarily
change the SIGINT handler to one that calls longjmp() to a safe point
in the Python wrapper.  This has to be extended to all caught signals
and all (or at least most) blocking calls, else the signal mechanism
would not be reliable.  I'll have to think about this long and deep
before I proceed to implement it...

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I think you have not fully appreciated our attitude towards the tenants"










Replied: Thu, 08 Oct 1992 00:30:31 +0100
Replied: [e-mail]
Received: from mcsun.EU.net by charon.cwi.nl with SMTP
    id AA15607 (5.65b/2.10/CWI-Amsterdam); Thu, 8 Oct 1992 00:10:19 +0100
Received: by mcsun.EU.net via EUnet
    id AA01700 (5.65b/CWI-2.179); Thu, 8 Oct 1992 00:10:17 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA05489; Wed, 7 Oct 92 19:04:08 -0400
Received: from decwrl.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 190356.5428; Wed, 7 Oct 1992 19:03:56 EDT
Received: by uucp-gw-1.pa.dec.com; id AA07545; Wed, 7 Oct 92 15:56:02 -0700
Received: from  lancelot.atherton.com  (lancelot) by eng.atherton.com (3.2/smail2.2/05-26-87)id AA17208; Wed, 7 Oct 92 15:35:12 PDT
Received: by  lancelot.atherton.com  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)id AA01220; Wed, 7 Oct 92 15:27:07 PDT
Date: Wed, 7 Oct 92 15:27:07 PDT
From: [e-mail] (Scott F. Rasmussen)
Message-Id: <9210072227.AA01220@ lancelot.atherton.com >
Received: by NeXT Mailer (1.63.RR)
To: [e-mail]
Subject: Need info on integrating python into my application

Hello everyone,

I have recently acquired python and trying to understand how to integrate python in with my
application.  I have looked through all the documentation but am still mystified by one question.  How
do I call a python function from C?  This is the typical callback situation.

In the callback I want to execute the following bit of python code.

def callback (args):
    stuff ....

In C how do I call the callback function?  The question is how do I get a handle to the function
callback so that I can call it.

Thank you for any help...

---

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=
Scott Rasmussen                                    [e-mail]
Atherton Technology                           {sun|decwrl}!athertn.com










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA17135 (5.65b/2.10/CWI-Amsterdam); Thu, 8 Oct 1992 00:30:31 +0100
Received: by voorn.cwi.nl with SMTP; Wed, 7 Oct 1992 23:30:30 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Need info on integrating python into my application
In-Reply-To: Your message of "Wed, 07 Oct 1992 15:27:07 MDT."
             <9210072227.AA01220@ lancelot.atherton.com >
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 08 Oct 1992 00:30:29 +0100
Sender: [e-mail]

>I have recently acquired python and trying to understand how to
>integrate python in with my
>application.  I have looked through all the documentation but am
>still mystified by one question.  How
>do I call a python function from C?  This is the typical callback situation.

If you have python 0.9.6 (and there's no reason not to have it), the
file misc/EXTENDING (the place to start if you want to integrate
Python and C code even if you don't want to add new modules) has a
section on calling a Python function from C.  The essential thing to
know is to use the function call_object(funcobj, argobj) and to
include <ceval.h> for its declaration (I think -- it's changed a bit
in the almost-0.9.7 version I'm currently using myself...).

>In the callback I want to execute the following bit of python code.
>
>def callback (args):
>    stuff ....
>
>In C how do I call the callback function?  The question is how do I
>get a handle to the function
>callback so that I can call it.

You call it using call_object().  To get a "handle" to the function,
you need a function object.  Most existing modules written in C that
use callbacks have some entry point with which the Python user
passes the callback function to the module, e.g. in the above example
there might be an external module "my_extension" with a function
"call_this_later" and the user might call it as follows (assuming the
above definition of callback():

      >>> my_extension.call_this_later(callback)

Cheers,

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Many of my best friends are lumberjacks and only a few of them are
transvestites"










To: [e-mail]
Subject: Re: Need info on integrating python into my application
In-reply-to: Your message of "Wed, 07 Oct 1992 15:27:07 MDT."
             <9210072227.AA01220@ lancelot.atherton.com >
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 08 Oct 1992 00:30:29 +0100
Sender: guido

>I have recently acquired python and trying to understand how to
>integrate python in with my
>application.  I have looked through all the documentation but am
>still mystified by one question.  How
>do I call a python function from C?  This is the typical callback situation.

If you have python 0.9.6 (and there's no reason not to have it), the
file misc/EXTENDING (the place to start if you want to integrate
Python and C code even if you don't want to add new modules) has a
section on calling a Python function from C.  The essential thing to
know is to use the function call_object(funcobj, argobj) and to
include <ceval.h> for its declaration (I think -- it's changed a bit
in the almost-0.9.7 version I'm currently using myself...).

>In the callback I want to execute the following bit of python code.
>
>def callback (args):
>    stuff ....
>
>In C how do I call the callback function?  The question is how do I
>get a handle to the function
>callback so that I can call it.

You call it using call_object().  To get a "handle" to the function,
you need a function object.  Most existing modules written in C that
use callbacks have some entry point with which the Python user
passes the callback function to the module, e.g. in the above example
there might be an external module "my_extension" with a function
"call_this_later" and the user might call it as follows (assuming the
above definition of callback():

      >>> my_extension.call_this_later(callback)

Cheers,

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Many of my best friends are lumberjacks and only a few of them are
transvestites"










Replied: Sun, 13 Dec 1992 20:56:09 +0100
Replied: "[e-mail] "
Replied: Mon, 16 Nov 1992 15:06:52 +0100
Replied: "python-list "
Received: from alpha.Xerox.COM by charon.cwi.nl with SMTP
    id AA19776 (5.65b/3.2/CWI-Amsterdam); Fri, 13 Nov 1992 17:11:37 +0100
Received: from aphrodite.EuroPARC.Xerox.COM ([13.1.252.142]) by alpha.xerox.com with SMTP id <12060>; Fri, 13 Nov 1992 08:11:15 PST
Received: by aphrodite.EuroPARC.Xerox.COM with SMTP
    (5.65c/IDA-1.2.9) id AA24783; Fri, 13 Nov 1992 16:09:29 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Ooops - sorry
Date:     Fri, 13 Nov 1992 08:09:27 PST
From: [e-mail]


Apologies for my silly message!

Firstly, many thanks for a wonderful product - I discovered python a few
days ago and haven't stopped playing since... :-)

I'm new to python, so forgive me if these are questions to which I should
know the answers...

1) Is there a digest of past messages?

2) Now that we have dynamic linking, has anybody done any stub generation
for Sun RPC?

Quentin










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA11361 (5.65b/3.2/CWI-Amsterdam); Mon, 16 Nov 1992 15:06:53 +0100
Received: by voorn.cwi.nl with SMTP
    id AA13720 (5.65b/3.2/CWI-Amsterdam); Mon, 16 Nov 1992 15:06:52 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Questions from [e-mail]
In-Reply-To: Your message of "Fri, 13 Nov 1992 08:09:27 MET."
             <[e-mail]>
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 16 Nov 1992 15:06:51 +0100
Sender: [e-mail]

>1) Is there a digest of past messages?

Not formally, but I have saved (almost) every message to the list
since November 1991 in an MH folder (i.e. one file per message).  I
can make this available by anonymous ftp.  Do people have preferences
for the format I should use?  I could make a tar file of the entire
folder, just copy all the files, or perhaps some fancy digest format.
Easiest to update for me would be a copy of the entire folder (I would
use rdist to add recent messages) but I can imagine this would be hard
to use.  If you have a preference, speak up!

>2) Now that we have dynamic linking, has anybody done any stub generation
>for Sun RPC?

Not me, sorry.

BTW if people who write useful Python code could mail it to me or at
least tell me about its existence, I can compile a catalog.  If you do
this within a week or two the catalog can be part of the next release,
0.9.8 (I'm going to skip 0.9.7 since a lot has changed since 0.9.7beta).

Cheers all,

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Oh mother, don't be so sentimental.  Things explode every day."










Received: from uunet.ca by charon.cwi.nl with SMTP
    id AA17614 (5.65b/3.2/CWI-Amsterdam); Mon, 16 Nov 1992 18:26:29 +0100
Received: from tslwat by mail.uunet.ca with UUCP id <9861>; Mon, 16 Nov 1992 12:26:16 -0500
Received: by research.teleride.on.ca (/\==/\ Smail3.1.25.1 #25.2)
    id <[e-mail]>; Mon, 16 Nov 92 11:06 EST
Message-Id: <[e-mail]>
From: [e-mail] (Lou Kates)
Subject: Re: Questions from [e-mail]
To: [e-mail]
Date:     Mon, 16 Nov 1992 11:06:00 -0500
In-Reply-To: <[e-mail]>; from "[e-mail]" at Nov 16, 92 9:06 am
X-Mailer: ELM [version 2.3 PL11]

>
> BTW if people who write useful Python code could mail it to me or at
> least tell me about its existence, I can compile a catalog.  If you do
> this within a week or two the catalog can be part of the next release,
> 0.9.8 (I'm going to skip 0.9.7 since a lot has changed since 0.9.7beta).
>

The   following    is  short,    uses  several python  libraries,
illustrates writing a  filter   and using  flags so its good  for
learning Python. I think you may have changed  the regexp library
since my copy of Python so we might  want to  change the function
names appropriately.

Lou Kates, [e-mail]


# swap fields x and y preserving whitespace; skip lines with too few fields
# eg:     python swapcols.py -x 2 -y 3 myfile.dat

import getopt, regexp, string, sys

options, files = getopt.getopt(sys.argv[1:], 'x:y:')

x, y = 1, 2
for (flag, value) in options:
        if 'x' in flag: x = string.atoi(value)
        if 'y' in flag: y = string.atoi(value)
if x > y: x, y = y, x

fp = sys.stdin
if files: fp = open(files[0], 'r')

while 1:
        line = fp.readline()
        if not line: break
        if len(string.split(line)) >= y:
                t = (regexp.compile('[ \t]*([^ \t]+)' * y)).exec(line)
                (a, b), (c, d) = t[x], t[y]
                line = line[:a] + line[c:d] + line[b:c] + line[a:b] + line[d:]
                print line[:-1]










To: [e-mail]
cc: Tim Berners-Lee <[e-mail]>
Subject: Python library documentation on-line
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 19 Nov 1992 18:11:45 +0100
Sender: guido

Thanks to Jan-Hein Buhrman, the library documentation for Python can
now be browsed on-line in two ways: as Emacs INFO tree (1) and as a
bunch of WWW hypertext nodes (2).

THANK YOU, JAN-HEIN!

(1) Emacs INFO tree

The library documentation is available in the format understood by the
Emacs INFO browser.  For this you need to fetch the tar file
python-lib-info.tar from anonymous ftp site ftp.cwi.nl
[192.16.184.180], directory /pub.

The tar file contains 6 compressed info files which together comprise
the entire info tree for the library manual.  You can go to the top of
the tree using the 'g' command in INFO mode, type g followed by
(python-lib), assuming the tar file has been extracted in the right
directory.  Of course you can also edit your "localdir" file.

You don't need Emacs to browse INFO files: if you uncompress the
info files, they can also be browsed with the info browser written in
Python from the Python distribution's demo directory,
python/demo/stdwin/ibrowse/ib.  (This requires that you have installed
the STDWIN extension to Python.)

(2) WWW hypertext

If you have a browser from CERN's WWW project (World-Wide Web, a
distributed hypertext system) you can browse a WWW hypertext version
of the manual by following the following link:

    http://voorn.cwi.nl:2784/texinfo/python/top.html

If your name server doesn't know about voorn.cwi.nl, substitute
192.16.201.121.  Try http://voorn.cwi.nl:2784/default.html to see
what other WWW documents are available from CWI -- I have converted
several other texinfo documents to WWW's format and made them
available, such as the Emacs manual.

It is possible that our Internet interface prohibits access to port
2784 on voorn.cwi.nl.  In that case, you can try the following slower
but equivalent access path using ftp:

    file://ftp.cwi.nl/pub/www/texinfo/python/top.html

Sources and binaries of WWW browsers can be ftp'ed from site
ftp.cern.ch, directory pub/www.  Start extracting README.txt.  The
Viola browser is quite worthwile (if you have X11).

I have also written a WWW browser in Python, but its displayer and
parser are rather slow compared to the C versions.  If you're
interested in the texinfo-to-WWW conversion program (also in Python),
send me mail.

Next projects: converting the reference manual and the tutorial...

Cheers,

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Now, are you going to give me a fish licence?"










Replied: Sun, 06 Dec 1992 15:13:50 +0100
Replied: "Lance Ellinghouse <[e-mail]> [e-mail]"
Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA16429 (5.65b/3.2/CWI-Amsterdam); Tue, 1 Dec 1992 20:02:29 +0100
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: Curses Interface
Date: Tue, 1 Dec 92 11:01:37 PST
Message-Id:  <[e-mail]>

Has anyone created a Curses interface layer (similar to STDWIN) for Python
yet?

Lance Ellinghouse
[e-mail]










Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA22246 (5.65b/3.2/CWI-Amsterdam); Tue, 1 Dec 1992 23:10:19 +0100
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: additional modules/objects
Date: Tue, 1 Dec 92 14:09:15 PST
Message-Id:  <[e-mail]>

Is "ftp.cwi.nl" the only place where Python modules/objects/scripts
are??? Does anyone else have any that are available?

Lance










Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP
    id AA16635 (5.65b/3.2/CWI-Amsterdam); Wed, 2 Dec 1992 10:54:32 +0100
Received: by schelvis.cwi.nl with SMTP
    id AA26559 (5.65b/3.2/CWI-Amsterdam); Wed, 2 Dec 1992 10:38:52 +0100
Message-Id: <[e-mail]>
To: Lance Ellinghouse <[e-mail]>
Cc: [e-mail]
Subject: Re: additional modules/objects
In-Reply-To: Message by Lance Ellinghouse <[e-mail]> ,
         Tue, 1 Dec 92 14:09:15 PST , <[e-mail]>
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone] (fax), [phone](home)
X-Last-Band-Seen: Alice Donut (Melkweg, 28-11)
X-Mini-Review: Good.
Date: Wed, 02 Dec 1992 10:38:52 +0100
From: Jack Jansen <[e-mail]>


Recently, Lance Ellinghouse <[e-mail]> said:
    Is "ftp.cwi.nl" the only place where Python modules/objects/scripts
    are??? Does anyone else have any that are available?

    Lance

If anyone has available modules that they feel would be of general
interest please also tell Guido, so he can include them in the distribution.
--
Jack Jansen        | If I can't dance I don't want to be part of
[e-mail] | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Replied: Sun, 06 Dec 1992 14:51:39 +0100
Replied: "[e-mail] python-list"
Received: from alpha.Xerox.COM by charon.cwi.nl with SMTP
    id AA18976 (5.65b/3.2/CWI-Amsterdam); Wed, 2 Dec 1992 12:07:17 +0100
Received: from aphrodite.EuroPARC.Xerox.COM ([13.1.252.142]) by alpha.xerox.com with SMTP id <11888>; Wed, 2 Dec 1992 03:06:59 PST
Received: by aphrodite.EuroPARC.Xerox.COM with SMTP
    (5.65c/IDA-1.2.9) id AA02797; Wed, 2 Dec 1992 11:05:09 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Curses Interface
In-Reply-To: Your message of "Tue, 01 Dec 92 11:01:37 PST."
             <[e-mail]>
Date:     Wed, 2 Dec 1992 03:05:01 PST
From: [e-mail]


> Has anyone created a Curses interface layer (similar to STDWIN) for
> Python yet?

I started to write a module for a subset of curses, called curselet, but
ran into problems with the dynamic loader. Can anyone suggest why the dl
system fails to find any of the symbols in my /usr/lib/libcurses.a? My
curseletmodule.libs contains just:

/usr/lib/libcurses.a /usr/lib/libc.a

and it finds things in libc.a, but I get :

dl_loadmod: dld_link of library failed: 10
dl_loadmod: 4 undefined symbols remain
_endwin
_wrefresh
_stdscr
_initscr
dl_loadmod: function initcurselet not executable

when I try and import curselet.

Thanks in advance.

Quentin

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Quentin Stafford-Fraser        Tel: [phone]
Rank Xerox EuroPARC,        Fax: [phone]
Cambridge, UK            [e-mail]











Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP
    id AA27738 (5.65b/3.2/CWI-Amsterdam); Wed, 2 Dec 1992 17:02:06 +0100
Received: by schelvis.cwi.nl with SMTP
    id AA27552 (5.65b/3.2/CWI-Amsterdam); Wed, 2 Dec 1992 17:02:05 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Curses Interface
In-Reply-To: Message by [e-mail] ,
         Wed, 2 Dec 1992 03:05:01 PST , <[e-mail]>
Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam
Phone: [phone](work), [phone] (fax), [phone](home)
X-Last-Band-Seen: Alice Donut (Melkweg, 28-11)
X-Mini-Review: Good.
Date: Wed, 02 Dec 1992 17:02:04 +0100
From: Jack Jansen <[e-mail]>

Hmm. You didn't mention what system you are using, but it is obviously
not an SGI, since dld is used for dynamic linking. A Sun?

I'd look at the two libraries (with 'file', for instance) to see if
they are compiled differently. On some systems libraries have to be
compiled in a funny way to allow them to work with dynamic loading.
Maybe your system admin can provide some help here.
--
Jack Jansen        | If I can't dance I don't want to be part of
[e-mail] | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl










Replied: Sun, 06 Dec 1992 15:05:15 +0100
Replied: "Lance Ellinghouse <[e-mail]> python-list"
Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA22860 (5.65b/3.2/CWI-Amsterdam); Thu, 3 Dec 1992 20:51:44 +0100
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: nice() in the os module?
Date: Thu, 3 Dec 92 11:50:33 PST
Message-Id:  <[e-mail]>

Why is there no 'nice()' function in the 'os' module?

Lance Ellinghouse
[e-mail]










Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA25311 (5.65b/3.2/CWI-Amsterdam); Thu, 3 Dec 1992 23:02:05 +0100
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: DOS version of Python 0.9.7beta
Date: Thu, 3 Dec 92 14:01:18 PST
Message-Id:  <[e-mail]>

Does anyone have Python 0.9.7beta compiled for MS-DOS?????

Thanks,
Lance Ellinghouse
[e-mail]










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA20841 (5.65b/3.2/CWI-Amsterdam); Sun, 6 Dec 1992 14:51:40 +0100
Received: by voorn.cwi.nl with SMTP
    id AA16027 (5.65b/3.2/CWI-Amsterdam); Sun, 6 Dec 1992 14:51:39 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Curses Interface
In-Reply-To: Your message of "Wed, 02 Dec 1992 03:05:01 MET."
             <[e-mail]>
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Sun, 06 Dec 1992 14:51:39 +0100
Sender: [e-mail]

>I started to write a module for a subset of curses, called curselet, but
>ran into problems with the dynamic loader. Can anyone suggest why the dl
>system fails to find any of the symbols in my /usr/lib/libcurses.a? My
>curseletmodule.libs contains just:
>
>/usr/lib/libcurses.a /usr/lib/libc.a
>
>and it finds things in libc.a, but I get :
>
>dl_loadmod: dld_link of library failed: 10
>dl_loadmod: 4 undefined symbols remain
>_endwin
>_wrefresh
>_stdscr
>_initscr
>dl_loadmod: function initcurselet not executable
>
>when I try and import curselet.

Hm, shouldn't you be using /usr/lib/libcurses_G0.a /usr/lib/libc_G0.a?
(Everything to be loaded dynamically has to be compiled with -G0 on
the SGI; SGI provides versions of some libraries compiled with -G0.)

Hope this helps,

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Afterlife, sir?  No, sir."










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA21582 (5.65b/3.2/CWI-Amsterdam); Sun, 6 Dec 1992 15:05:17 +0100
Received: by voorn.cwi.nl with SMTP
    id AA16068 (5.65b/3.2/CWI-Amsterdam); Sun, 6 Dec 1992 15:05:16 +0100
Message-Id: <[e-mail]>
To: Lance Ellinghouse <[e-mail]>
Cc: [e-mail]
Subject: Re: nice() in the os module?
In-Reply-To: Your message of "Thu, 03 Dec 1992 11:50:33 MET."
             <[e-mail]>
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Sun, 06 Dec 1992 15:05:15 +0100
Sender: [e-mail]

>Why is there no 'nice()' function in the 'os' module?

Because no-one needed it before and I didn't think it would be very
useful.  After all you can also run a script using the nice(1)
command.  And, I don't believe this is part of the POSIX standard.
If you want it you can add it to posixmodule.c with only a few lines.
If enough people want it I can add it to 0.9.8.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Well there's spam, egg, sausage and spam.  That's not got *much* spam
in it"










To: Lance Ellinghouse <[e-mail]>
cc: [e-mail]
Subject: Re: Curses Interface
In-reply-to: Your message of "Tue, 01 Dec 1992 11:01:37 MET."
             <[e-mail]>
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Sun, 06 Dec 1992 15:13:50 +0100
Sender: guido

>Has anyone created a Curses interface layer (similar to STDWIN) for Python
>yet?

Note that there is a "curses-like" version of stdwin, where you can
use the stdwin API (or at least a large subset) and run the program on
an ASCII terminal.  Look at stdwin/Ports/alfa and vtrm.  You'll have
to build a separate Python interpreted for this, linked with this
alternative stdwin library.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>

PS: It seems I replied to quick about the "dl" question: as Jack
notices, this isn't on an SGI platforms.  Sorry for bothering you
folks...










Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA01893 (5.65b/3.2/CWI-Amsterdam); Mon, 7 Dec 1992 19:45:10 +0100
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: Re: Curses Interface
Cc: [e-mail]
Date: Mon, 7 Dec 92 10:44:04 PST
Message-Id:  <[e-mail]>

> >Has anyone created a Curses interface layer (similar to STDWIN) for Python
> >yet?

> Note that there is a "curses-like" version of stdwin, where you can
> use the stdwin API (or at least a large subset) and run the program on
> an ASCII terminal.  Look at stdwin/Ports/alfa and vtrm.  You'll have
> to build a separate Python interpreted for this, linked with this
> alternative stdwin library.

The problem is that I then have to constantly port another package
whenever updates come about... If I use the standard CURSES libs, I
don't have to worry about it.

Lance Ellinghouse
[e-mail]











Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA01646 (5.65b/3.2/CWI-Amsterdam); Tue, 15 Dec 1992 12:27:53 +0100
Received: by voorn.cwi.nl with SMTP
    id AA09507 (5.65b/3.2/CWI-Amsterdam); Tue, 15 Dec 1992 12:27:50 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: DOS version of Python
In-Reply-To: Your message of "Mon, 14 Dec 1992 16:34:56 MET."
             <[e-mail]>
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Tue, 15 Dec 1992 12:27:49 +0100
Sender: [e-mail]

>Has ANYONE compiled a DOS version of Python yet?????

Yes, you can ftp it from ftp.cwi.nl, directory pub, file python0.9.6.zip.
I didn't compile it, and can't test it, so you are on your own using
it though. I have heard that there are some minor problems with it
(e.g. list.index() returning a wrong value and there may be a problem
with breaking out of a loop sometimes), but basically it is fully
functioning.  The "posix" module supports all the Unix functions that
are reasonably implementable on DOS.

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Exploding is a perfectly normal medical phenomenon."










Replied: Wed, 16 Dec 1992 10:32:49 +0100
Replied: Lance Ellinghouse <[e-mail]>
Replied: [e-mail]
Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA15949 (5.65b/3.2/CWI-Amsterdam); Wed, 16 Dec 1992 00:47:02 +0100
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: something simple..
Date: Tue, 15 Dec 92 15:46:21 PST
Message-Id:  <[e-mail]>

I must be missing something here...
I have a string ( t = '10.4' ) and I want to make
this into a float type so I can do some addition and such on
it..

How do I do this??????

Thanks,
Lance Ellinghouse
[e-mail]










Received: from hermix.markv.com by charon.cwi.nl with SMTP
    id AA01783 (5.65b/3.2/CWI-Amsterdam); Wed, 16 Dec 1992 03:46:49 +0100
From: Lance Ellinghouse <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
To: [e-mail]
Subject: Re: DOS version of Python
Date: Tue, 15 Dec 92 18:46:20 PST
Message-Id:  <[e-mail]>

The DOS version on ftp.cwi.nl is corrupted.. don't
waste your time or bandwidth getting it.. :(

Lance










To: Lance Ellinghouse <[e-mail]>
cc: [e-mail]
Subject: Re: something simple..
In-reply-to: Your message of "Tue, 15 Dec 1992 15:46:21 MET."
             <[e-mail]>
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Wed, 16 Dec 1992 10:32:47 +0100
Sender: guido

>I must be missing something here...
>I have a string ( t = '10.4' ) and I want to make
>this into a float type so I can do some addition and such on
>it..

Try the built-in function eval()...

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"He knew how to treat a female impersonator"










To: Lance Ellinghouse <[e-mail]>
Subject: Re: DOS version of Python
In-reply-to: Your message of "Wed, 16 Dec 1992 10:12:21 MET."
             <[e-mail]>
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Thu, 17 Dec 1992 11:10:15 +0100
Sender: guido

>I used binary twice..
>I tried "pkunzip -t" to test it.. said CRC error...

OK, I'll see what I can do.  It unpacks here but I have no idea if the
unix unzip program test the crc at all.

Sorry,

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"I'm afraid we're fresh out of Red Leicester, sir"










Received: from uvaarpa.Virginia.EDU by charon.cwi.nl with SMTP
    id AA19708 (5.65b/3.3/CWI-Amsterdam); Fri, 18 Dec 1992 18:22:36 +0100
Received: from elvis.med.virginia.edu by uvaarpa.Virginia.EDU id aa01572;
          18 Dec 92 12:22 EST
Received: by elvis.med.Virginia.EDU (5.65c/1.34)
    id AA19306; Fri, 18 Dec 1992 12:22:32 -0500
From: "Steven D. Majewski" <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: Building Python 0.9.7b for IBM/AIX-6000 with GL support
To: [e-mail]
Date: Fri, 18 Dec 92 12:22:31 EST
In-Reply-To: <[e-mail]>; from "Steven D. Majewski" at Dec 18, 92 12:07 pm
X-In-Reply-To: "myself" <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]


I suppose the *proper* way around this is to modify cstubs & cgen.py
to generate the correct glmodule.c for AIX.

Any tips on this before I try to decipher the source and figure out
what it's doing.

[ If that is the solution, then this will probably have to wait till
  January. ]

- Steve Majewski











Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA19713 (5.65b/3.3/CWI-Amsterdam); Fri, 18 Dec 1992 18:23:06 +0100
Received: by voorn.cwi.nl with SMTP
    id AA19028 (5.65b/3.2/CWI-Amsterdam); Fri, 18 Dec 1992 18:23:06 +0100
Message-Id: <[e-mail]>
To: "Steven D. Majewski" <[e-mail]>
Cc: [e-mail]
Subject: Re: Building Python 0.9.7b for IBM/AIX-6000 with GL support
In-Reply-To: Your message of "Fri, 18 Dec 1992 12:07:16 MET."
             <[e-mail]>
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Fri, 18 Dec 1992 18:23:05 +0100
Sender: [e-mail]

>I have managed to rebuild Python 0.9.7b successfully on my new IBM RS6000.
>( I haven't been active on this list lately - I've been busy trying to port
>  a lot of stuff off of our old VAX-750 onto various PC's, Mac's & unixes. )

[Some stuff deleted -- I'll see if I can make the necessary changes in
the Makefile to make life easier in this case...]

>Now, I've been trying to rebuild it with GL support.
[...]
>|.endpupmode
>|.pupmode
>|.dglclose
>|.dglopen
>|.qgetfd
[...]
>dglclose & dglopen are on the list of unsupported functions.
>( Meaning, they SHOULD be there for the linker to resolve, but they don't DO
>anything! )
>
>endpupmode & popmode are listed on the obsolete list, but they aren't
>defined in the glports.h include file.
>
>And I can't find qgetfd at all!

My suggestion: edit the "cstubs" file, commenting out the lines that
define these functions.  Then regenerate glmodule.c (Make should do
this automatically) and then relink.  These functions are all
non-essential.  See demo/sgi/gl for some examples...

I'll remove all from the next release, except qgetfd, which is
essential for some applications, but I may add a note to the
installation notes.

(In a hurry,)

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Well I'm a plumber.  I can't act"










Replied: Mon, 21 Dec 1992 18:35:44 +0100
Replied: "python-list "
Received: from uvaarpa.Virginia.EDU by charon.cwi.nl with SMTP
    id AA02891 (5.65b/3.4/CWI-Amsterdam); Mon, 21 Dec 1992 16:53:50 +0100
Received: from elvis.med.virginia.edu by uvaarpa.Virginia.EDU id aa05646;
          21 Dec 92 10:53 EST
Received: by elvis.med.Virginia.EDU (5.65c/1.34)
    id AA13407; Mon, 21 Dec 1992 10:53:47 -0500
Date: Mon, 21 Dec 1992 10:46:15 [phone] (EST)
From: "Steven D. Majewski" <[e-mail]>
Subject: sockets, fork() & makefile()
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


I'm trying to open a socket, fork(), dup a file descriptor with makefile(),
assign  to sys.stdin and exec() another procedure.

And it's not working quite right.
Should it?

The assignment to stdin and exec is the bit that I am suspicious of - will
python actually export that assignment ?

[ In the mean time, I'll go back and check over the code again - maybe I'm
  closing something that shouldn't have been closed... ]

===============================================================================
 Steven D. Majewski            University of Virginia
 [e-mail]            Box 449 Health Sciences Center
 Voice: (804)-982-0831            1300 Jefferson Park Avenue
 FAX:   [phone]            Charlottesville, VA 22908
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Former UVA Department of Physiology, now Department of Molecular Physiology
and Biological Physics! [ Still the same spacious offices in Jordan Hall
- only the letterhead has changed! ]











Received: from uvaarpa.Virginia.EDU by charon.cwi.nl with SMTP
    id AA02891 (5.65b/3.4/CWI-Amsterdam); Mon, 21 Dec 1992 16:53:50 +0100
Received: from elvis.med.virginia.edu by uvaarpa.Virginia.EDU id aa05646;
          21 Dec 92 10:53 EST
Received: by elvis.med.Virginia.EDU (5.65c/1.34)
    id AA13407; Mon, 21 Dec 1992 10:53:47 -0500
Date: Mon, 21 Dec 1992 10:46:15 [phone] (EST)
From: "Steven D. Majewski" <[e-mail]>
Subject: sockets, fork() & makefile()
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


I'm trying to open a socket, fork(), dup a file descriptor with makefile(),
assign  to sys.stdin and exec() another procedure.

And it's not working quite right.
Should it?

The assignment to stdin and exec is the bit that I am suspicious of - will
python actually export that assignment ?

[ In the mean time, I'll go back and check over the code again - maybe I'm
  closing something that shouldn't have been closed... ]

===============================================================================
 Steven D. Majewski            University of Virginia
 [e-mail]            Box 449 Health Sciences Center
 Voice: (804)-982-0831            1300 Jefferson Park Avenue
 FAX:   [phone]            Charlottesville, VA 22908
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Former UVA Department of Physiology, now Department of Molecular Physiology
and Biological Physics! [ Still the same spacious offices in Jordan Hall
- only the letterhead has changed! ]











Replied: Mon, 21 Dec 1992 22:22:07 +0100
Replied: "[e-mail] "
Received: from meerman.cwi.nl by charon.cwi.nl with SMTP
    id AA00637 (5.65b/3.4/CWI-Amsterdam); Mon, 21 Dec 1992 20:25:26 +0100
Received: from uvaarpa.Virginia.EDU by meermin.cwi.nl with SMTP
    id AA22693 (5.65b/3.2/CWI-Amsterdam); Mon, 21 Dec 1992 17:45:22 +0100
Received: from elvis.med.virginia.edu by uvaarpa.Virginia.EDU id aa09885;
          21 Dec 92 11:44 EST
Received: by elvis.med.Virginia.EDU (5.65c/1.34)
    id AA09651; Mon, 21 Dec 1992 11:44:19 -0500
Date: Mon, 21 Dec 1992 11:39:21 [phone] (EST)
From: "Steven D. Majewski" <[e-mail]>
Subject: Re: Building Python 0.9.7b for IBM/AIX-6000 with GL support
To: [e-mail]
Cc: "Steven D. Majewski" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



Thanks Guido, it works.
For anyone else who wants it ( till that time that you have the time
to fold these changes into Configure.py ) here are instructions.

To Build python 0.9.7b for IBM/rs6000 AIX with GL library support:


In "Makefile", Uncomment the GL option, except replace line:

> #GL_LIBS=    -lgl_s

with:

> GL_LIBS=    -lgl            # for AIX


GL for AIX does not include a number of "obsolete" GL functions.
Some of these have stubs in "/usr/lpp/GL/examples/glport.h"
( See the comments in that file and the info entry for GL compatibility
  for further notes. )

In "cstubs", insert the following lines among the other #include lines:

> #define    _GL_PORT_C_    1            /* (sdm7g) for AIX */
> #include "/usr/lpp/GL/examples/glport.h"        /* (sdm7g) for AIX */

This will not remove ALL of the unresolved names. You must also comment out
the following function definitions in cstubs:

> ### void    endpupmode              # not in aix GL (sdm7g)
> ### void    pupmode                # not in aix GL (sdm7g)

> ### void dglclose        long s        # not in aix GL (sdm7g)
> ### long dglopen        char *s long s    # not in aix GL (sdm7g)

> ### long qgetfd        # but not in aix GL  (sdm7g)


The last one is apparenlty, not an old obsolete GL function, but a new one
which is not included in IBM's AIX GL.


Most of the python/demo/sgi/gl  programs appear to work except for nurbs,
which gives this error message:

> $ python nurbs.py
> MemoryError
> Stack backtrace (innermost last):
>   File "nurbs.py", line 171
>     main()
>   File "nurbs.py", line 77
>     make_lights()
>   File "nurbs.py", line 152
>     lmdef(DEFLMODEL,1,[])

There may be a few other hidden traps, since some of the code might assume that
if you have GL, you are running a SGI, and therefore may have other sgi libraries
and functions.


! Next project - maybe I can figure out how to write an AIX audio module.
! but that may have to wait till after adding sockets to Mac/Dos python,
! which is something I actually NEED!

===============================================================================
 Steven D. Majewski            University of Virginia
 [e-mail]            Box 449 Health Sciences Center
 Voice: (804)-982-0831            1300 Jefferson Park Avenue
 FAX:   [phone]            Charlottesville, VA 22908
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Former UVA Department of Physiology, now Department of Molecular Physiology
and Biological Physics! [ Still the same spacious offices in Jordan Hall
- only the letterhead has changed! ]











Received: from uvaarpa.Virginia.EDU by charon.cwi.nl with SMTP
    id AA01108 (5.65b/3.4/CWI-Amsterdam); Mon, 21 Dec 1992 21:03:43 +0100
Received: from elvis.med.virginia.edu by uvaarpa.Virginia.EDU id aa24926;
          21 Dec 92 15:03 EST
Received: by elvis.med.Virginia.EDU (5.65c/1.34)
    id AA11195; Mon, 21 Dec 1992 15:03:24 -0500
Date: Mon, 21 Dec 1992 14:46:43 [phone] (EST)
From: "Steven D. Majewski" <[e-mail]>
Subject: Re: sockets, fork() & makefile()
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


I wrote:
sdm7g>The assignment to stdin and exec is the bit that I am suspicious of - will
sdm7g>python actually export that assignment ?

On Mon, 21 Dec 1992 [e-mail] wrote:

>
> No, I'm sorry, it doesn't.  I suggest you use popen() and construct a
> piece of shell syntax to redirect the socket's file number to 0,
> something like
>
>     sock = socket(...) # Create a socket
>     cmd = 'some_program arg1 arg2 ...' # A command and its arguments
>     fd = sock.fileno() # Get the socket's file number as an integer
>     cmd = cmd + ' 0<&' + `fd` # Append "0&<N" where N is the file number
>     pipe = os.popen(cmd, 'w') # Fork+exec the program; it ignores its stdin
>     pipe.close() # Write an EOF on the pipe
>

Thanks.
socket.fileno() is not in my copy of the library reference, but I *do* see
it there with  "mysocket.__methods__" .
Your example, above, should be sufficient - I just want a python script that
will read in an initial command from a socket and dispatch to another
program, with input and output reassigned to the socket.


===============================================================================
 Steven D. Majewski            University of Virginia
 [e-mail]            Box 449 Health Sciences Center
 Voice: (804)-982-0831            1300 Jefferson Park Avenue
 FAX:   [phone]            Charlottesville, VA 22908
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Former UVA Department of Physiology, now Department of Molecular Physiology
and Biological Physics! [ Still the same spacious offices in Jordan Hall
- only the letterhead has changed! ]











Received: from meerman.cwi.nl by charon.cwi.nl with SMTP
    id AA00532 (5.65b/3.4/CWI-Amsterdam); Mon, 21 Dec 1992 20:25:07 +0100
Received: from voorn.cwi.nl by meermin.cwi.nl with SMTP
    id AA23038 (5.65b/3.2/CWI-Amsterdam); Mon, 21 Dec 1992 18:37:02 +0100
Received: by voorn.cwi.nl with SMTP; Mon, 21 Dec 1992 17:35:47 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: sockets, fork() & makefile()
In-Reply-To: Your message of "Mon, 21 Dec 1992 10:46:15."
             <[e-mail]>
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 21 Dec 1992 18:35:44 +0100
Sender: [e-mail]

>I'm trying to open a socket, fork(), dup a file descriptor with makefile(),
>assign  to sys.stdin and exec() another procedure.
>
>And it's not working quite right.
>Should it?
>
>The assignment to stdin and exec is the bit that I am suspicious of - will
>python actually export that assignment ?

No, I'm sorry, it doesn't.  I suggest you use popen() and construct a
piece of shell syntax to redirect the socket's file number to 0,
something like

    sock = socket(...) # Create a socket
    cmd = 'some_program arg1 arg2 ...' # A command and its arguments
    fd = sock.fileno() # Get the socket's file number as an integer
    cmd = cmd + ' 0<&' + `fd` # Append "0&<N" where N is the file number
    pipe = os.popen(cmd, 'w') # Fork+exec the program; it ignores its stdin
    pipe.close() # Write an EOF on the pipe


I could hack something in exec() to dup the file descriptors from
sys.std{in,out,err} back to 0, 1, 2, except that (in a yet unreleased
version) it is possible to replace any file with a class instance, as
long as the instance has a write() method or read() and readline()
methods.  In this case, what should I use for the file descriptor in
the exec'ed process?


Maybe it's better to provide low-level operations posix.dup(i),
posix.open(...), posix.close(i) etc. and an fdopen()-like interface,
so that if necessary you can do anything you like yourself (some
programs may want special files open as fd 5...).  This, however, has
the disadvantage that uninformed use can cause unexplainable problems,
e.g. what if a novice user accidentally closes fd 1...


--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"Look matey, this parrot wouldn't voom if I put four thousand volts
through it"










Received: from voorn.cwi.nl by charon.cwi.nl with SMTP
    id AA03565 (5.65b/3.4/CWI-Amsterdam); Mon, 21 Dec 1992 22:22:08 +0100
Received: by voorn.cwi.nl with SMTP
    id AA00584 (5.65b/3.2/CWI-Amsterdam); Mon, 21 Dec 1992 22:22:08 +0100
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Building Python 0.9.7b for IBM/AIX-6000 with GL support
In-Reply-To: Your message of "Mon, 21 Dec 1992 11:39:21."
             <[e-mail]>
From: [e-mail]
X-Organization: CWI, Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
X-Phone: [phone] (work), [phone] (home), [phone] (fax)
Date: Mon, 21 Dec 1992 22:22:07 +0100
Sender: [e-mail]

>Most of the python/demo/sgi/gl  programs appear to work except for nurbs,
>which gives this error message:
>
>> $ python nurbs.py
>> MemoryError
>> Stack backtrace (innermost last):
>>   File "nurbs.py", line 171
>>     main()
>>   File "nurbs.py", line 77
>>     make_lights()
>>   File "nurbs.py", line 152
>>     lmdef(DEFLMODEL,1,[])

By sheer coincidence I ran into this myself the other day.  God knows
how long it has been there waiting until I tried those old demos
again!

The cause is simple: the empty list [] is being copied to a malloc'ed
array of floats which causes a call to malloc(0). This returns NULL on
some systems, and of course the check for malloc errors takes that as
an error return.  This can happen in other situations too.

As a temporary measure (though this is a waste of some memory), I
added 1 to the malloc and realloc arguments in the definitions of NEW
and RENEW in [my]malloc.h (the file's name changed at I don't know
which release):

/* XXX Always allocate one extra byte, since some malloc's return NULL
   XXX for malloc(0) or realloc(p, 0). */
#define NEW(type, n) ( (type *) malloc(1 + (n) * sizeof(type)) )
#define RESIZE(p, type, n) \
    if ((p) == NULL) \
        (p) =  (type *) malloc(1 + (n) * sizeof(type)); \
    else \
        (p) = (type *) realloc((ANY *)(p), 1 + (n) * sizeof(type))

Eventually I'll probably use a less wasteful fix (Python is a really
heavy malloc user and every byte counts!).

I wonder -- will I really have to use a configure script like the GNU
software uses?  I'd much rather write portable code that doesn't need
to be configured, but I hate it if it gets wasteful that way...

--Guido van Rossum, CWI, Amsterdam <[e-mail]>
"The man from the cat-detector van."










Received: from relay2.UU.NET by charon.cwi.nl with SMTP
    id AA11065 (5.65b/3.5/CWI-Amsterdam); Wed, 23 Dec 1992 16:02:22 +0100
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AA12685; Wed, 23 Dec 92 10:02:13 -0500
Received: from astro.UUCP by uunet.uu.net with UUCP/RMAIL
    (queueing-rmail) id 100149.15581; Wed, 23 Dec 1992 10:01:49 EST
Received: by astro.sunrise.com (/\==/\ Smail3.1.22.1 #22.3)
    id <[e-mail]>; Wed, 23 Dec 92 08:57 EST
Message-Id: <[e-mail]>
From: [e-mail] (Drew Jenkins)
Subject: Subscribe
To: [e-mail]
Date: Wed, 23 Dec 92 8:57:17 EST
X-Mailer: ELM [version 2.3 PL11]

Guido,

Please add me to the python mailing list.

Thanks,

Drew Jenkins            "Attitude is Everything"
[e-mail]                 -- Bingen Bart